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1.0  INTRODUCTION 

This  users  manual  provides  the  operating  instructions  for  the  Require- 
ments Engineering  and  Validation  System  (REVS)  software  and  the  definition 
of  the  Requirements  Statement  Language  (RSL)  which  is  processed  by  REVS. 

This  software  system  and  language  provide  unique  capabilities  to  write, 
analyze,  simulate,  and  document  software  requirements.  Although  they  were 
designed  to  meet  the  needs  of  Ballistic  Missile  Defense  (BMD)  systems  and 
other  large  weapon  systems  with  imbedded  real-time  software,  they  are 
applicable  to  a broad  range  of  applications.  RSL  and  REVS  provide  a degree 
of  precision,  automation,  and  confidence  in  software  requirements  develop- 
ment unattainable  by  conventional  means. 

This  manual  is  organized  into  five  parts  to  facilitate  use  by  readers 
at  all  levels  of  familiarity  with  the  material  beyond  a basic  understanding 
of  the  underlying  approach: 

• Part  I (Section  2)  provides  an  introductory  overview  of  the 
software  and  the  language. 

• Part  II  (Section  3)  describes  the  concepts  of  RSL. 

• Part  III  (Sections  4 through  8)  describes  the  RSL  syntax 
and  the  commands  and  operating  instructions  for  each  of  the 
REVS  functions. 

• Part  IV  (Sections  9 and  10)  describes  the  job  control  language 
and  the  installation  unique  characteristics  for  REVS. 

• Part  V (Appendices)  provides  background  and  reference 
material.  This  material  includes  an  explanation  of  the 
extended  Backus-Naur  Form  (BNF)  used  to  define  language 
constructs  and  various  summaries  of  RSL.  The  appendices  also 
contain  the  syntax  of  the  REVS  control  language  and  explana- 
tions of  REVS  messages  and  diagnostics.  This  material  pro- 
vides the  quick  reference  needed  by  users  of  RSL  who  are  already 
familiar  with  the  underlying  concepts  and  by  users  of  REVS  who 
are  familiar  with  the  capabilities  of  each  of  the  REVS  functions. 

As  with  all  software  users  manuals,  this  manual  presents  the  instruc- 
tions for  using  the  software  and  language,  but  does  not  contain  an  explana- 
tion of  how  to  apply  these  capabilities  to  the  development  of  software 
requirements.  The  engineering  application  of  these  capabilities  is  described 
In  the  Software  Requirements  Engineering  Methodology,  which  is  Volume  I of 
this  report. 
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2.0  OVERVIEW  OF  RSL  AND  REVS 

The  Requirements  Statement  Language  (RSL)  provides  the  user  with  the 
ability  to  define  software  requirements  in  a form  which  assures  unambiguous 
communication  of  explicit,  testable  requirements.  RSL  combines  the  reada- 
bility of  English  with  the  rigor  of  a computer-readable  language.  The 
Requirements  Engineering  and  Validation  System  (REVS)  provides  facilities 
for  translating,  storing,  analyzing,  simulating,  and  documenting  require- 
ments written  in  RSL.  Through  the  use  of  RSL  and  REVS,  the  engineer  can 
verify  the  completeness  and  consistency  jf  a software  specification  with  a 
high  degree  of  confidence. 


The  common  practice  of  organizing  software  requirements  into  a 
hierarchy  of  functions,  subfunctions,  etc.,  while  superficially  appealing, 
leads  to  difficulties  in  both  the  expression  and  verification/validation 
of  the  requirements.  This  is  due  in  part  to  the  fact  that  such  an  organi- 
zation does  not  fit  the  basic  input-process-output  nature  of  data  pro- 
cessing, and  in  part  to  the  fact  that  a hierarchical  tree  of  arbitrarily 
defined  "functions"  does  not  have  a sufficiently  rigorous  mathematical 
basis  to  allow  automated  analysis  of  completeness  and  consistency  properties 
of  the  resulting  specification.  To  avoid  these  difficulties,  RSL  and  REVS 
are  based  on  the  concept  of  processing  flow.  Software  requirements  written 
in  RSL  are  formulated  in  terms  of  a mathematical  network  (graph  model) 
called  a Requirements  Network  (R-Net).  This  approach  provides  several 
advantages: 

• Describing  the  required  processing  in  terms  of  a "logic 
diagram"  of  the  system  is  natural  to  most  engineers. 

0 The  mathematical  properties  of  an  R-Net  allow  automated 
analysis  for  consistency  and  completeness  through  the 
application  of  graph  theory. 

0 The  flow  orientation  of  an  R-Net  allows  automated  generation 
of  simulations  directly  from  the  stated  requirements. 

The  remainder  of  this  section  presents  an  overview  of  the  concepts 
of  R-Nets,  the  concepts  of  RSL,  and  the  capabilities  of  REVS. 
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2.1  REQUIREMENTS  NETWORKS  (R_NETS) 

Flows  through  a system  are  specified  in  RSL  as  Requirements  Networks 
called  R_NETs.  R_NET  flow  structures  consist  of  nodes  which  specify  required 
processing  operations  and  connecting  arcs.  The  basic  nodes  are  INPUT_ 
INTERFACES,  OUTPUT_INTERFACEs , and  required  processing  activities  called 
ALPHAS.  Through  the  use  of  these  basic  nodes,  the  required  paths  of  pro- 
cessing can  be  specified.  For  example,  if  data  is  to  be  input  to  the  data 
processor  through  an  INPUT_INTERFACE  called  A,  processed  by  a processing 
step  (ALPHA)  called  B,  then  processed  by  an  ALPHA  called  C,  and  the  result 
output  through  an  OUTPUT_INTERFACE  called  D,  then  the  required  processing 
path  can  be  specified  by  listing  the  sequence  of  operations: 

INPUTJNTERFACE:  A 

ALPHA:  B 

ALPHA:  C 

OUTPUTJNTERFACE:  D 

This  simple  R_NET  is  illustrated  graphically  in  Figure  2-1. 

In  the  above  example,  the  sequence  B-C  means  that  those  processing 
steps  must  be  performed  in  the  indicated  sequence.  In  many  cases,  the  actual 
order  of  processing  is  immaterial.  This  is  specified  through  the  use  of  an 
AND  node  as  shown  in  Figure  2-2.  This  structure  means  that  both  B and  C 
must  be  performed  after  receipt  of  data  through  A and  before  the  result  is 
output  through  D,  but  B and  C are  sequentially  independent  and  may  be  per- 
formed in  any  order  (or  in  parallel). 

Most  systems  also  require  the  specification  of  decision  (control) 
points.  Thus,  in  the  above  example,  if  B is  to  be  performed  under  some 
circumstances  (depending  on  the  value  of  the  input  data  for  example)  and 
C is  to  be  performed  otherwise,  a decision  point  ano  its  attendant  decision 
criterion  must  be  specified.  This  is  specified  in  an  R_NET  through  the  use 
of  an  OR  node  as  illustrated  in  Figure  2-3.  The  second  OR  node  following 
B and  C means  that  processing  is  to  continue  (i.e.,  output  result  through 
D)  if  processing  on  any  input  branch  has  been  completed. 
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Figure  2-3  Use  of  OR  Nodes  In  R_NETs 

Through  the  use  of  the  three  basic  nodes  plus  AND  and  OR  nodes, 
complete,  complex  processing  requirements  can  be  readily  specified.  Other 
nodes  are  provided  to  specify  selection  of  data  to  be  processed  (SELECT, 
FOR  EACH),  "test  points"  for  specifying  performance  requirements  (VALIDA- 
TI0N_P0INTs),  internal  controls  (EVENTs),  and  detailed  processing  flows 
(SUBNETs).  These  concepts  are  described  in  detail  in  Section  3. 


2.2  REQUIREMENTS  STATEMENT  LANGUAGE  (RSL) 


RSL  is  a machine-readable,  English-like  language  for  stating  software 
requirements.  The  basic  structure  of  RSL  is  very  simple  and  is  based  on 
four  primitive  language  concepts:  elements,  attributes,  relationships,  and 
structures. 


El  ements 

Elements  in  RSL  correspond  roughly  to  nouns  in  English.  They 
are  those  objects  and  ideas  which  the  requirements  analyst  uses 
as  building  blocks  for  his  description  of  the  system  require- 
ments. Each  element  has  a unique  name  and  belongs  to  one  of  a 
number  of  classes  called  element  types.  Some  examples  of  standard 
element  types  in  RSL  are  ALPHA  (the  class  of  functional  processing 
steps),  DATA  (the  class  of  conceptual  pieces  of  data  necessary  in 
the  system),  and  R_NET  (the  class  of  processing  flow  specifications). 


Attributes 


Attributes  are  modifiers  of  elements  somewhat  in  the  manner  of 
adjectives  in  English;  they  formalize  important  properties  of  the 
elements.  Each  attribute  has  associated  with  it  a set  of  values 
which  may  be  mnemonic  names,  numbers,  or  text  strings.  Each 
particular  element  may  have  only  one  of  these  values  for  any 
attribute.  An  example  of  an  attribute  is  INITIAL_VALUE  which  Is 
applicable  to  elements  of  type  DATA.  It  has  values  which  specify 
what  the  initial  value  for  the  data  item  must  be  in  the  implemented 
software  and  for  simulations. 


Relationships 

The  relationship  (or  relation)  in  RSL  may  be  compared  with  an  English 
verb.  More  properly.  It  corresponds  to  the  mathematical  definition 
of  a binary  relation,  a statement  of  an  association  of  some  type 
between  two  elements.  The  RSL  relationship  is  non-commutative;  it 
has  a subject  element  and  an  object  element  which  are  distinct. 

However,  there  exists  a complementary  relationship  for  each  specified 
relationship  which  is  the  converse  of  that  specified  relationship. 

ALPHA  INPUTS  DATA  Is  one  of  the  relationships  in  RSL;  the  complementary 
relationship  says  that  DATA  is  INPUT  to  an  ALPHA. 
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Structures 


The  final  RSL  primitive  is  the  structure,  the  RSL  representation 
of  the  flow  graph.  Two  distinct  types  of  structures  have  been 
identified.  The  first  is  the  R_NET  (or  SUBNET)  structure.  It 
identifies  the  flow  through  the  functional  processing  steps  (ALPHAs) 
and  is  thus  used  to  specify  the  system  response  to  various  stimuli. 
The  second  structure  type  is  the  VALIDATION_PATH,  which  is  used  to 
specify  performance  of  the  system. 


Through  the  use  of  these  four  primitive  language  concepts,  a basic 
requirements  language  is  provided  which  includes  concepts  for  specifying 
processing  flows,  data,  processing  actions,  and  timing  and  accuracy  require- 
ments. In  addition,  informative  and  descriptive  material,  and  management- 
related  information  may  be  specified.  The  concepts  of  this  baseline 
language,  consisting  of  twenty-one  element  types,  twenty-one  attributes, 
twenty-three  relationships,  and  two  types  of  structures,  are  described 
in  detail  in  Section  3.  Section  5.1  describes  the  syntax  of  the  language. 

RSL  can  be  extended  to  include  additional  concepts  by  defining  new 
element  types,  attributes,  or  relationships.  This  allows  the  language  to 
be  tailored  to  the  needs  of  a specific  problem  or  project.  The  explana- 
tion of  how  to  extend  the  language  is  provided  in  Section  8. 
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2.3  REQUIREMENTS  ENGINEERING  AND  VALIDATION  SYSTEM  (REVS) 


The  Requirements  Engineering  and  Validation  System  (REVS)  is  an 
integrated  system  of  software  which  aids  in  the  development,  maintenance, 
validation,  and  documentation  of  software  requirements.  REVS  is  designed 
to  allow  the  requirements  engineer  to  state  and  modify  requirements  infor- 
mation over  a period  of  time  as  the  requirements  are  developed.  The  RSL 
statements  that  an  engineer  inputs  to  REVS  are  analyzed,  and  a representa- 
tion of  the  information  is  put  into  a centralized  data  base.  This  data  base 
is  called  the  Abstract  System  Semantic  Model  (ASSM)  because  It  maintains 
information  about  the  required  data  processing  system  (RSL  semantics)  in  an 
abstract,  relational  model.  Once  entered  into  the  ASSM,  the  requirements  are 
available  for  subsequent  refinement,  extraction,  and  analysis  by  the  REVS 
software. 

From  a user  point  of  view  there  are  five  major  functional  capabilities 
which  REVS  provides: 

• Processing  of  RSL. 

• Interactive  generation  of  Requirements  Networks  (R_NETs). 

• Analysis  of  requirements  and  output  of  requirements  in  RSL 
and/or  in  specially  formatted  reports. 

• Generation  and  execution  of  functional  and  analytic  simula- 
tors from  functional  requirements  and  models  or  algorithms, 
and  the  generation  and  execution  of  simulation  post  processors 
from  analytic  performance  requirements. 

• Processing  of  extensions  to  RSL. 

REVS  and  RSL  allow  the  engineer  to  enter  requirements  into  REVS  as 
they  are  developed,  with  REVS  accumulating  the  information  in  the  require- 
ments data  base  and  checking  for  consistency  and  completeness  as  new  data 
is  entered.  Consequently,  although  the  REVS  capabilities  may  be  applied 
in  any  order,  in  o:>neral,  the  user  will  initially  enter  RSL  and  request 
various  analyse'  to  be  performed.  New  entries  will  be  made  and  analysis 
repeated  until  the  requirements  have  been  developed  sufficiently  for  a 
simulation  to  be  meaningful  and  useful.  At  that  time  a simulator  and  post 
processor  may  be  generated.  The  simulator  may  then  be  executed  numerous 
times  and  the  data  recorded  and  analyzed.  Based  on  the  results,  this 
sequence  may  be  repeated,  starting  with  the  modification  of  requirements 
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already  input  to  REVS  or  the  addition  of  new  ones.  The  sequence  will  also 
be  repeated  as  system  requirements  change  or  new  requirements  are  Imposed. 
When  the  user  is  satisfied  that  the  requirements  are  correct,  based  upon  the 
results  of  static  and  dynamic  analysis,  REVS  will  document  the  requirements 
in  a form  directly  usable  in  a software  requirements  specification. 

Each  of  the  major  capabilities  identified  above  is  allocated  to  a 
different  functional  component  of  REVS.  The  capabilities  and  the  appropriate 
functions  are  described  briefly  below. 


Processing  cf  RSL 


The  analysis  of  RSL  statements  and  the  establishment  of  entries  in 
the  ASSM  corresponding  to  the  meaning  of  the  statements  is  performed  by  the 
RSL  translation  function  of  REVS  (see  Section  5.1).  The  translation  function 
also  processes  the  modifications  and  deletions  from  the  data  base  commanded 
by  RSL  statements  specifying  changes  to  already-existing  entries  in  the  data 
base.  For  all  types  of  input  processing,  the  RSL  translation  function 
references  the  ASSM  to  do  simple  consistency  checks  on  the  input.  This 
prevents  disastrous  errors  such  as  the  introduction  of  an  element  with  the 
same  name  as  a previously-existing  element  or  an  instance  of  a relationship 
which  is  tied  to  an  illegal  type  of  element.  Besides  providing  a measure 
of  protection  for  the  data  base,  this  type  of  checking  catches,  at  an  early 
stage,  some  of  the  simple  types  of  inconsistencies  that  are  often  founa  in 
requirements  specifications,  without  restricting  the  order  in  which  the  user 
adds  to  or  alters  the  data  base. 


Interactive  Generation  of  R-Nets 

Graphics  capabilities  to  interactively  input,  modify  or  display  R_NET, 
SUBNET,  and  VALIDATION_PATH  structures  are  provided  through  the  REVS  Inter- 
active R-Net  Generation  (RNETGEN)  function.  RNETGEN  permits  entry  of 
structures  and  referenced  elements  in  a manner  parallel  to  the  RSL  trans- 
lator and  thus  provides  an  alternative  to  the  RSL  translator  for  the  speci- 
fication of  the  flow  portion  of  the  requirements.  Using  this  function,  the 
user  may  develop  (either  automatically  or  under  direct  user  control)  a 
graphical  representation  of  a structure  previously  entered  in  RSL.  Through 
the  use  of  the  ASSM,  the  user  may  work  with  either  the  graphical  or  RSL 
language  representation  of  a structure;  they  are  completely  interchangeable. 
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The  Interactive  R-Net  Generation  facility  contains  full  editing  capa- 
bilities. The  user  may  input  a new  structure  or  he  may  modify  one  previously 
entered.  At  the  conclusion  of  the  editing  session,  the  user  may  elect  to 
replace  the  old  structure  with  the  modified  one.  The  editing  functions  pro- 
vide means  to  position,  connect,  and  delete  nodes,  to  move  them,  to  disconnect 
them  from  other  nodes  and  to  enter  or  change  their  associated  names  and 
commentary.  The  size  of  a structure  is  not  limited  by  the  screen;  zoom-in, 
zoom-out,  and  scroll  functions  are  provided.  Details  of  the  RNETGEN  capa- 
bilities are  presented  in  Section  5.2. 

Analysis  and  Output  of  Requirements 

The  Requirements  Analysis  and  Data  Extraction  (RADX)  function  pro- 
vides both  static  flow  analysis  capabilities  and  the  capabilities  of  a 
generalized  extractor  system  to  support  both  the  checking  for  completeness 
and  consistency  in  the  requirements  specification  and  the  development  of 
requirements  documentation  (see  Section  6.0). 

The  static  flow  analysis  deals  with  data  flow  through  the  R_NETs. 

The  analysis  uses  the  R_NET  structure  in  much  the  same  manner  that  data 
flow  analyzers  for  programming  languages  use  the  control  flow  of  the  pro- 
gram to  detect  deficiencies  in  the  flow  of  processing  and  data  manipula- 
tion stated  in  the  requirements. 

The  generalized  extractor  system  allows  the  user  to  perform  additional 
analysis  and  to  extract  information  from  the  ASSM.  The  user  can  subset  the 
elements  in  the  ASSM  based  on  some  condition  (or  combination  of  conditions) 
and  display  the  elements  of  the  subset  with  any  appended  Information  he 
selects. 

Information  to  be  retrieved  is  identified  in  terms  of  RSL  concepts. 

For  example,  if  the  user  wants  a report  listing  all  DATA  elements  which  are 
not  INPUT  to  any  ALPHA  (processing  step),  he  enters  the  following  comnands: 

SET  A = DATA  THAT  IS  NOT  INPUT. 

LIST  A. 

By  combining  sets  in  various  ways,  he  can  detect  the  absence  or  presence  of 
data,  trace  references  on  the  structures,  and  analyze  interrelationships 
established  in  the  ASSM.  In  analyzing  user  requests  and  extracting  infor- 
mation from  the  ASSM,  the  extractor  system  uses  the  definition  of  the 
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language  concepts  contained  in  the  ASSM.  Thus,  as  RSL  is  extended,  the 
extensions  and  their  use  in  the  requirements  are  available  for  extraction. 

Generation  and  Execution  of  Simulators  and  Post  Processors 

The  automatic  Simulation  Generation  (SIMGEN)  function  in  REVS  takes 
the  ASSM  representation  of  the  requirements  of  a data  processing  system 
and  generates  from  it  discrete  event  simulators  of  the  system.  These 
simulators  are  driven  by  externally  generated  stimuli;  the  baseline  system 
generates  simulators  to  be  driven  by  a System  Environment  and  Threat 
Simulation  (SETS)  type  of  driver  program  which  models  the  threat,  the 
system  environment,  and  the  components  of  a ballistic  missile  defense 
system  external  to  the  data  processing  system. 

Two  distinct  types  of  simulators  may  be  generated  by  REVS.  The 
first  uses  functional  models  of  the  processing  steps  and  may  employ  simpli- 
fications to  simulate  the  required  processing.  This  type  of  simulation 
serves  as  a means  to  validate  the  overall  required  flow  of  processing 
against  higher  level  system  requirements. 

The  other  type  of  simulator  uses  analytic  models;  i.e.,  models  that 
use  algorithms  similar  to  those  which  will  appear  in  the  software  to  per- 
form complex  computations.  This  type  of  simulation  may  be  used  to  define 
a set  of  algorithms  which  have  the  desired  accuracy  and  stability.  Real- 
time feasibility  of  a system  using  this  algorithm  set  is  not  established 
for  any  implementation;  instead  the  simulation  provides  an  existence  proof 
of  an  analytic  solution  to  the  problem.  Both  types  of  simulations  are  used 
to  check  dynamic  system  interactions. 

The  SIMGEN  function  transforms  the  ASSM  representation  of  the  require- 
ments into  simulation  code  in  the  programming  language  PASCAL.  The  flow 
structure  of  each  R_NET  is  used  to  develop  a PASCAL  procedure  whose  control 
flow  implements  that  of  the  R_NET  structure.  Each  processing  step  (ALPHA) 
on  the  R_NET  becomes  a call  to  a procedure  consisting  of  the  model  or 
algorithm  for  the  ALPHA.  The  models  or  algorithms  are  written  in  PASCAL. 

The  data  definitions  and  structure  for  the  simulation  are  synthesized  from 
the  requirements  data  elements  and  their  relationships  and  attributes  in 
the  ASSM. 
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By  automatically  generating  simulators  in  this  manner  from  the  ASSM, 
the  simulations  are  insured  to  match  and  trace  to  the  requirements.  New 
simulators  can  be  generated  readily  as  requirements  change;  all  changes 
are  made  to  the  requirements  statements  themselves,  and  are  automatically 
reflected  in  the  next  generation  of  the  simulator. 

For  analytic  simulations,  SIMGEN  also  generates  simulation  post  pro- 
cessors based  on  the  statement  of  performance  requirements  In  the  ASSM. 

Data  collected  from  an  analytic  simulation  can  be  evaluated  using  the 
corresponding  post  processor  to  test  that  the  set  of  algorithms  meet  the 
required  accuracies. 

Both  REVS  generated  simulators  and  post  processors  are  accessed  for 
execution  through  REVS  functions;  the  Simulation  Execution  (SIMXQT)  function 
for  simulators,  and  the  Simulation  Data  Analysis  (SIMDA)  function  for  simu- 
lation post  processors.  The  REVS  generation  and  execution  of  simulators  and 
post  processors  is  detailed  in  Section  7. 

Processing  Extensions  to  RSL 

An  ASSM  contains  the  RSL  concepts  used  to  express  requirements  as 
well  as  the  requirements.  Extensions  and  modifications  to  the  concepts 
are  processed  by  the  RSL  Extension  translation  (RSLXTND)  function  of  REVS 
as  described  in  Section  8.  The  RSLXTND  function  is  actually  performed  by 
the  same  software  as  RSL  translation  but  is  accessed  separately  to  control 
extensions  to  the  language  through  a lock  mechanism  built  into  the  software. 

REVS  Organization 

The  above  discussion  has  identified  seven  functions  of  REVS:  RSL, 
RNETGEN,  RADX,  SIMGEN,  SIMXQT,  SIMDA  and  RSLXTND.  As  shown  in  Figure  2-4, 
these  functions  are  under  the  control  of  a higher  level  function,  the  REVS 
Executive.  The  Executive  presents  a unified  interface  between  the  user 
and  the  different  REVS  functions.  The  organization  of  conmand  input  to 
REVS  and  the  REVS  controls  available  at  the  Executive  level  are  described 
in  Section  4. 
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Figure  2-4  REVS  Functional  Organization 


Installation  of  REVS  operates  either  from  card  input  (termed  off-line  mode) 
or  Interactively  (termed  on-line  mode)  using  the  Data  Disc  Color  Graphics 
(ANAGRAPH)  Display  System  Terminal.  In  the  on-line  mode,  all  of  the  functions 
described  above  are  available  to  the  user  and  may  be  invoked  in  any  order. 

In  the  off-line  mode,  all  functions  except  RNETGEN  may  be  utilized  in  any 
order.  The  NRL  Installation  of  REVS  operates  only  In  the  off-line  mode. 

An  explanation  of  the  job  control  stream  required  to  execute  REVS  on  either 
of  these  ASCs  is  documented  in  Section  9.^ 


REVS  will  be  operational  In  July  1977  on  a Control  Data  Corporation  (CDC) 
7600  at  the  ARC.  This  machine  also  Interfaces  with  the  ANAGRAPH  terminal. 
A supplement  to  this  volume  documenting  REVS  operation  on  the  CDC  7600  will 
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3.0  REQUIREMENTS  STATEMENT  LANGUAGE 
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RSL  is  a concept-oriented  language  based  on  the  four  primitives  of 
elements,  relationships,  attributes,  and  structures  as  described  in 
Section  2.  The  unit  for  writing  requirements  In  RSL  Is  the  element  deflnl 
tlon.  An  element  definition  Is  very  similar  to  a paragraph  In  English. 

It  consists  of  one  or  more  sentences,  the  first  of  which  is  a topic 
sentence.  The  topic  sentence  gives  the  element  type  and  the  name  of  the 
element  being  defined.  The  other  sentences  in  the  definition  give  the 
attributes  and  values,  relationships,  and  structures  pertaining  to  the 
subject  element. 

The  characteristics  of  structures  and  the  element  types,  relation- 
ships, and  attributes  currently  defined  for  writing  requirements  are 
presented  in  this  section.  The  presentation  is  divided  into  segments. 
Loosely,  a segment  consists  of  a group  of  element  types,  relationships, 
attributes,  and  structures  which  arise  from  some  underlying  issue  of 
requirements  definition.  Element  definitions  containing  concepts  from 
different  segments  may  be  intermixed  at  will.  However,  the  presentation 
of  the  predefined  concepts  of  the  language  will  be  arranged  by  segments 
in  order  to  take  advantage  of  the  logical  consistency  afforded  by  this 
view. 

This  section  presents  only  the  concepts  of  RSL.  The  syntax  for 
writing  RSL  element  definitions  is  provided  in  Section  5.1. 


3.1  DATA  SEGMENT 


The  concepts  In  the  Data  Segment  of  RSL  address  the  logical  relation- 
ships among  pieces  of  Information  and  the  interactions  of  this  information 
with  the  rest  of  the  software  system.  Since  RSL  is  used  to  describe 
software  requirements,  not  design,  the  Data  Segment  concepts  address  only 
logical  relationships,  not  physical  ones  such  as  access  methods,  file  organi- 
zations, etc.  The  emphasis  Is  on  concepts  such  as  hierarchical  relationships, 
us*  of  data  by  various  system  components,  and  access  to  data  using  only 
properties  of  that  data. 

3.1.1  Data  and  Hierarchies 

The  RSL  element  type  DATA  is  the  class  of  conceptual  pieces  of  infor- 
mation necessary  in  the  system  and  includes  the  meaning  of  "datum",  "data 
item",  "data  set",  and  "data".  DATA  may  have  rather  obvious  relationships 
with  other  elements;  it  may  be  INPUT  to  and  OUTPUT  from  ALPHAS  (the  basic 
processing  steps  stated  in  requirements,  see  Section  3.2)  and  RECORDED  by 
VALIDATION_POINTs  (the  required  software  test  points,  see  Section  3.4). 

DATA  may  also  be  organized  into  hierarchies  using  the  RSL  relationship 
INCLUDES  between  DATA.  This  simple  data  hierarchy  is  depicted  pictorially 
below. 


The  requirements  engineer  might  define  A to  be  DATA  and  also  define  B to 
be  DATA.  He  might  then  define  DATA  C to  INCLUDE  both  DATA  A and  DATA  B. 

If  he  did  so,  then  obtaining  C would  be  exactly  equivalent  to  obtaining 
both  A and  B,  and  we  could  say  that  A and  B are  parts  of  the  hierarchy  of  C. 

DATA  C may  also  be  INCLUDED  in  DATA  D.  Thus  by  the  INCLUDES  rela- 


tionship, DATA  A,  B,  and  C are  part  of  the  hierarchy  of  D.  DATA  m?y  be 
INCLUDED  in  other  DATA  in  this  manner  to  form  any  depth  of  hierarchy  as 
long  as  no  DATA  item  Is  repeated  (this  would  specify  a loop  in  the 
hierarchy,  which  is  not  meaningful).  Clearly,  the  only  DATA  which  assume 
values  and  are  thus  required  in  the  real-time  software  are  the  DATA  com- 
prising the  lowest  level  of  a hierarchy  (in  our  example,  DATA  A and  B).  The 
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DATA  at  higher  levels  are  simply  collective  names  used  for  clarity  and 
convenience. 

Care  should  be  taken  in  using  INCLUDES  In  conjunction  with  other 
relationships.  Specifically,  a relationship  between  DATA  and  a particular 
element  should  not  be  repeated  at  multiple  levels  of  a hierarchy.  To 
illustrate  using  our  example,  if  DATA  C is  INPUT  to  an  ALPHA,  the  engineer 
should  not  also  state  that  DATA  A and  B are  INPUT  to  the  ALPHA.  This 
redundant  information  is  unnecessary  --  since  inputting  C means,  by  the 
definition  of  INCLUDES, that  A and  B are  input.  Furthermore,  the  informa- 
tion may  be  misleading  and  confusing  to  the  reader. 

3.1.2  Files 

In  RSL,  DATA  does  not  include  any  repeating  lower  levels  of  DATA;  C 
cannot  INCLUDE  A and  n instances  of  B.  Instead,  this  situation  is  repre- 
sented as  a DATA  item  named  A and  a FILE  named  D;  D CONTAINS  instances  of 
DATA  B.  An  RSL  FILE,  therefore,  is  a more  general  concept  than  a software 
file  since  a FILE  also  subsumes  the  concepts  of  arrays  and  sequences.  The 
relationships  CONTAINS  and  INCLUDES  form  a hierarchy  for  defining  the 
constituents  of  a FILE: 


A FILE  can  CONTAIN  any  number  of  DATA;  a single  DATA,  however,  is 
CONTAINED  in  only  one  FILE.  Each  DATA  (and  its  hierarchy)  CONTAINED  in  a 
FILE  is  repeated  in  each  instance  (record)  of  the  FILE.  The  nu..iber  of 
records  in  a FILE  is  not  predetermined;  Instances  are  entered  or  removed 
by  the  actions  of  ALPHAS. 

A FILE  can  be  INPUT  to  an  ALPHA, implying  that  the  entire  FILE  is 
accessible  and  that  one  or  more  instances  are  retrieved  from  the  FILE;  a 
FILE  which  is  only  INPUT  may  not  be  altered.  The  accessing  of  a TILE  can 
be  either: 


' 
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• ordered  (because  FILES  are  ordered  either  first-in-first- 
out  — the  default  — or  ORDERED  least  to  greatest  on  any 
one  lowest  level  DATA  CONTAINED  in  the  FILE),  or 

• associatively  (by  SELECTing  the  instances  that  meet  some 

criterion).  , 

A FILE  can  also  be  OUTPUT  from  an  ALPHA;  such  specification  implies 
that  data  have  been  added,  deleted,  or  in  some  way  modified.  The  rela- 
tionships INPUTS  and  OUTPUTS  between  anALPHA  and  DATA  CONTAINED  in  a FILE 
specify  the  particular  DATA  in  the  FILE  records  which  are  affected.  The 
details  of  the  FILE  access  are  specified  within  the  description  of  the 
ALPHA. 

A FILE  can  be  RECORDED  by  a VALIDATION_POINT  identifying  that  the 
entire  FILE  is  to  be  made  available  for  validation  purposes.  The  relation 
ship  RECORDS  between  a VALIDATION_POINT  and  DATA  CONTAINED  In  the  FILE 
specifies  the  particular  DATA  which  are  to  be  RECORDED  from  each  record  in 
the  FILE. 

3.1.3  Interfaces  and  Messages 

Interfaces  exist  in  real-time  software  between  the  data  processing 
subsystem  and  other  components  of  the  system;  these  interfaces  are  re- 
flected in  two  element  types  in  RSL.  An  INPUT_INTERFACE  in  RSL  denotes  an 
interface  through  which  DATA  is  communicated  into  the  data  processing  sub- 
system. An  OUTPUT_INTERFACE  is  one  through  which  DATA  is  communicated  out 
of  the  data  processing  subsystem.  In  RSL,  each  interface  CONNECTS  the 
data  processing  subsystem  to  some  other  SUBSYSTEM. 

MESSAGES  are  the  aggregation  of  DATA  and  FILES  that  are  communicated 
as  logical  units  across  interfaces.  DATA  and  FILES  MAKE  up  MESSAGES;  a 
single  DATA  or  FILE  may  MAKE  several  MESSAGES.  A single  INPUT_INTERFACE 
or  OUTPUT_INTERFACE  may  PASS  several  different  MESSAGES  to  or  from  the 
data  processing  subsystem.  A given  MESSAGE  may  be  PASSED  through  only  one 
interface.  The  DATA  and  FILES  that  an  INPUT  INTERFACE  or  OUT  PUT_I  NT  ERF AC  E 
corrmunicates  can  be  ascertained  by  reference  to  the  definition  of  all 
MESSAGES  that  PASS  through  the  interface.  These  relationships,  combined 
with  the  FILE  and  DATA  hierarchy  relationships,  form  an  additional 
hierarchy  for  associating  information: 
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An  ALPHA  on  an  R_NET  path  preceding  an  0UTPUT_I NTERFAC E FORMS  one 
of  the  MESSAGES  which  the  interface  PASSES;  that  is,  it  indicates  which 
of  the  legal  MESSAGES  the  OUTPUTJ NTERFAC E will  PASS  when  the  path  is 
traversed  and  the  interface  encountered  on  an  invocation  of  the  R_NET. 

3.1.4  Entity  Types  and  Entity  Classes 

In  real-time  control  systems  the  software  is  generally  required  to 
maintain  information  about  objects  external  to  the  data  processing  system. 
This  is  represented  in  RSL  using  entities.  One  clear  example  of  an  entity 
in  a BMD  system  is  an  image  — the  thing  in  space  which  the  BMD  system 
detects,  tracks,  discriminates,  and  possibly  intercepts.  An  ALPHA  can 
CREATE  and  DESTROY  the  knowledge  that  an  instance  of  an  entity  belonging 
to  a particular  ENTITY_CLASS  exists  in  the  environment. 

To  reflect  the  state  of  the  data  processing  system's  knowledge  about 
the  entity  and  thus  the  "status"  of  the  entity,  entities  belonging  to  an 
ENTITY_CLASS  are  subsetted  into  ENTITYJYPEs;  an  ENTITY_CLASS  is  COMPOSED 
of  ENTITY_TYPEs.  As  the  data  processing  system  gathers  information  about 
an  entity,  it  may  first  identify  the  entity  as  being  of  one  ENTITY_TYPE, 
and  then  another.  Instances  of  a class  of  entities  thus  evolve  from  one 
type  to  another,  but  instances  of  one  class  (e.g.,  images)  can  never  evolve 
into  another  class  (e.g.,  interceptors).  Each  ENTITY_TYPE  therefore 
COMPOSES  just  one  ENTITY_CLASS;  an  ENTITY_CLASS  is  COMPOSED  of  at  least 
one  ENTITY__TYPE.  An  instance  belongs  to  one  ENTITY_CLASS  after  an  ALPHA 
has  CREATED  it,  and  it  belongs  to  the  last  ENTITY_TYPE  (within  that  CLASS) 
to  which  an  ALPHA  SETS  it.  Eventually,  an  ALPHA  DESTROYS  the  instance. 
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ASSOCIATED  with  each  ENTITY_CLASS  may  be  DATA  and/or  FILES  which 
are  required  to  be  set  up  whenever  the  knowledge  about  a new  instance  in 
the  ENTITY_CLASS  is  CREATED  by  an  ALPHA.  These  DATA  and  FILEs  are  main- 
tained for  the  entity  instance  through  changes  to  the  ENTITY_TYPE  until 
the  instance  is  DESTROYED  by  an  ALPHA. 

DATA  and  FILEs  may  also  be  ASSOCIATED  with  ENTITYJYPEs.  Thus,  in 
addition  to  the  class  ASSOCIATED  information,  an  entity  instance  may  have 
different  DATA  and  FILEs  ASSOCIATED  with  it  as  it  changes  ENTITY_TYPE. 

DATA  and  FILEs  ASSOCIATED  with  an  ENTITY_TYPE  may  be  unique  to  the  type 
or  common  to  several  types  composing  the  same  ENTITY_CLASS.  As  an  ALPHA 
SETS  an  ENTITY_TYPE  for  an  instance,  DATA  and  FILEs  common  to  the  previous 
and  new  ENTITY_TYPE  retain  their  values  through  the  change.  These  rela- 
tionships, combined  with  INCLUDES  and  CONTAINS,  form  the  final  data  related 
hierarchy  as  depicted  below: 


As  described  above,  in  addition  to  simple  DATA  hierarchies  (DATA 
INCLUDES  DATA),  RSL  provides  several  complex  hierarchies  dealing  with  DATA: 
FILES,  interfaces  and  MESSAGES,  and  ENTITY_TYPEs  and  ENTITY_CLASSes.  When 
DATA  and  FILEs  are  INPUT  to  or  OUTPUT  from  an  ALPHA,  there  must  be  a 
unique  identification  of  the  DATA  and  FILEs  in  order  for  the  specification 
to  be  unambiguous.  Consequently,  certain  conventions  should  be  followed 
in  writing  RSL  in  order  to  establish  this  uniqueness. 
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The  conventions  dealing  with  the  individual  constructs  have  been 
stated  in  the  previous  sections  introducing  the  related  concepts  (e.g.,  a 
single  DATA  item  (or  its  hierarchy)  is  CONTAINED  in  only  one  FILE).  In 
addition  there  are  conventions  which  apply  to  all  of  the  constructs  and 
between  constructs. 

As  illustrated  in  Figure  3-1,  a simple  data  hierarchy  may  be  used  as 
a component  of  the  complex  hierarchies.  To  form  complex  hierarchies  the 
defining  relationships  CONTAINS,  MADE  BY  and  ASSOCIATES  should  be  used  with 
only  two  types  of  DATA: 

• simple  DATA  - DATA  which  neither  INCLUDES  DATA  nor  is  INCLUDED 
in  DATA,  and 

• DATA  which  forms  the  top  of  a hierarchy  - DATA  which  INCLUDES 
DATA  but  which  is  not  itself  INCLUDED  in  DATA. 

When  DATA  of  the  second  type  listed  above  is  defined  as  part  of  a complex 
hierarchy,  all  of  its  INCLUDED  DATA  (to  all  levels  of  inclusion)  become 
part  of  the  hierarchy.  The  defining  relationships  are  never  associated 
directly  with  DATA  at  more  than  one  level  of  inclusion. 

In  general,  DATA  may  not  appear  in  more  than  one  complex  hierarchy. 

For  example,  DATA  CONTAINED  in  a FILE  may  not  also  MAKE  a MESSAGE  nor  may 
it  be  ASSOCIATED  with  an  entity  (although  the  FILE  may  have  either  of 
these  two  relationships).  The  two  exceptions  to  this  rule  are  1)  that  DATA 
(meaning  both  types  of  DATA  described  above)  may  MAKE  more  than  one  MESSAGE 
and  2)  that  DATA  may  be  ASSOCIATED  with  several  ENTITY_TYPEs  provided  the 
ENTITYJYPEs  COMPOSE  the  same  ENTITY_CLASS. 

The  FILE  hierarchy  is  a component  of  the  Interface/MESSAGE  and 
ENTITY_CLASS/ENTITY_TYPE  hierarchies.  Conventions  similar  to  those  for 
DATA  apply  to  FILES.  A FILE  cannot  appear  In  both  an  Interface/ 

MESSAGE  hierarchy  and  an  ENTITY_CLASS/ENTITY_TYPE  hierarchy.  A FILE  may 
MAKE  several  MESSAGES.  A FILE  may  be  ASSOCIATED  with  several  ENTITYJYPEs 
if  the  types  COMPOSE  a single  ENTITY_CLASS.  Finally,  DATA  and  FILES 
ASSOCIATED  with  an  ENTITY_CLASS  may  not  also  be  ASSOCIATED  with  any 
ENTITYJYPEs. 

This  near  absolute  separation  of  the  names  in  data  defining 
hierarchies  assures  uniqueness  of  the  static  DATA  definitions.  However, 
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entity  instances  and  records  in  FILEs  are  created  and  destroyed  dynamically; 


thus,  these  conventions  do  not  address  the  identification  of  particular 
instances  of  DATA.  The  identification  of  a particular  entity  instance  is 
accomplished  on  the  R_NETs  (see  Section  3.3);  identification  of  instances 
in  a FILE  is  done  on  the  R_NETs  and  in  ALPHAS  (see  Sections  3.3  and  3.2 
respectively) . 

3.1.6  Locality 

DATA  and  FILEs  may  have  different  required  accessibil itles  and  1 ifetimes 
in  the  system.  The  range  of  accessibility  of  an  item  is  denoted  by  the 
attribute  LOCALITY,  which  may  have  values  of  LOCAL  or  GLOBAL.  Items  of  DATA 
or  FILEs  which  are  LOCAL  are  associated  with  the  R_NETs  in  which  they  are 
used  and  are  unknown  outside  of  these  R_NETs.  Implicit  in  this  definition 
is  a concept  of  permanence:  LOCAL  DATA  exists  only  during  the  invocation 
of  the  R_NET  to  which  it  is  LOCAL.  It  does  not  exist  prior  to  R_NET  ENABLE- 
ment  and  ceases  to  exist  when  the  R_NET  terminates. 

Since  ALPHAS  which  use  LOCAL  DATA  and  FILEs  may  appear  on  more  than 
one  R_NET,  it  is  possible  for  a single  DATA  item  or  a FILE  to  be  LOCAL  to 
more  than  one  R_NET.  These  are  different  instances  of  the  DATA  or  FILE 
which  have  no  relation  to  each  other;  they  have  completely  separate  existences 
which  are  controlled  by  the  R_NETs  in  question. 

GLOBAL  DATA  and  FILEs  are  accessible  by  more  than  one  R_NET  and  exist 
over  a longer  period  of  time  than  an  R_NET  invocation  --  in  fact  they  may 
be  permanently  in  the  global  data  base  and  exist  throughout  the  duration  of 
the  system. 

Certain  DATA  and  FILEs  have  an  intrinsic  locality.  DATA  and  FILEs 
which  are  ASSOCIATED  with  an  ENTITY_TYPE  or  an  ENTITY_CLASS  are  tied  to  the 
entity  instances  to  which  they  belong.  They  are  created  when  the  instance 
is  CREATED  and  last  until  the  instance  is  DESTROYED  and  are  thus  GLOBAL. 

DATA  and  FILEs  which  MAKE  a MESSAGE  are  LOCAL.  They  either  are  passed  to 
the  R_NET  from  an  external  source  at  R_NET  ENABLEment,  or  are  established 
during  execution  of  the  nets;  they  either  cease  to  exist  or  exit  the  data 
processing  subsystem  when  the  R_NET  terminates. 
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The  lifetime  alternatives  are  therefore: 


DATA 

FILE 


MAKES  a MESSAGE 

Transient  (during  invocation  of  an  R_NET) 
ASSOCIATED  with  an  ENTITY_TYPE  or  ENTITY_CLASS 
Permanent  (default) 


Thus,  it  is  necessary  to  assign  the  LOCALITY  attribute  only  to  those  LOCAL 
DATA  and  FILES  which  do  not  MAKE  a MESSAGE.  When  assigning  LOCALITY  to  a 
FILE  it  is  not  necessary  to  also  assign  LOCALITY  to  the  lowest  level  of 
DATA  CONTAINED  in  the  FILE.  However,  if  the  DATA  has  LOCALITY  it  must  match 
that  of  the  FILE. 


3.1.7  Typing  and  Usage 

As  described  in  Section  3.3,  DATA  are  used  in  branching  criteria  on 
R_NETs  to  determine  the  flow  of  processing.  To  understand  these  branching 
criteria,  TYPE  information  must  be  provided  about  the  DATA.  The  attribute 
TYPE  may  have  values  REAL,  INTEGER,  BOOLEAN,  or  ENUMERATION.  A DATA  item 
with  TYPE  ENUMERATION  has  values  which  are  denoted  by  identifiers  given  in 
the  RANGE  attribute,  which  is  legal  only  for  DATA  items  which  are. enumerated. 
An  example  of  the  use  of  the  enumerated  type  follows: 

DATA:  COLOR. 

TYPE:  ENUMERATION. 

RANGE:  "RED,  BLUE,  YELLOW,  GREEN". 

Clearly,  for  stating  requirements  the  attribute  TYPE  is  assigned  to  only 
simple  DATA  or  DATA  at  the  lowest  level  of  a hierarchy  (e.g.,  simple  data, 
FILE,  Interface/MESSAGE,  or  ENTITY_CLASS/ENTITY_TYPE  hierarchy). 

TYPE  information  must  also  be  provided  for  simulation  purposes.  For 
simulations,  models  of  the  required  processing  steps  are  written.  These 
models  may  be  either  functional  models  (termed  BETAs)  or  analytic  models 
(termed  GAMMAs).  An  analytic  simulation  (one  which  uses  GAMMAs)  by  defini- 
tion simulates  the  lowest  level  of  DATA  --  the  requirements  level.  Thus, 
the  TYPE  attribute  is  always  assigned  for  gamma  simulations  as  it  is  for 
requirements  --  on  either  simple  DATA  or  DATA  at  the  lowest  level  of  a 
hierarchy. 
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A functional  simulation  (using  BETAs)  may  employ  DATA  only  part  way 
down  a hierarchy.  That  is,  the  simulation  may  use  one  DATA  to  represent 
all  or  a part  of  a hierarchy.  For  example,  a beta  simulation  may  use  the 
DATA  POSITION  to  represent  the  DATA  X,  Y,  and  Z INCLUDED  in  POSITION.  Thus, 
in  order  for  the  simulation  to  execute,  the  TYPE  attribute  must  be  assigned 
to  DATA  POSITION. 

Qualification  of  the  use  of  a DATA  item  in  simulation  and  interpreta- 
tion of  TYPE  is  given  by  the  attribute  USE.  The  value  of  this  attribute 
may  be  BETA,  GAMMA,  or  BOTH  denoting  that  the  DATA  item  is  the  lowest  level 
in  the  data  hierarchy  which  will  be  used  in  the  corresponding  simulation. 

The  lowest  level  of  DATA  must  always  have  either  USE  GAMMA  or  USE  BOTH. 

Thus  in  our  example,  DATA  POSITION  would  have  USE  BETA;  DATA  X,  Y,  and  Z 
would  have  USE  GAMMA;  and  DATA  POSITION,  X,  Y,  and  Z would  have  specified  TYPES. 

3.1.8  Values 

In  stating  software  requirements  the  engineer  may  specify  the  attributes 
UNITS,  MAXIMUM JALUE,  MINIMUM JALUE,  INITIALJ/ALUE,  and  RESOLUTION  at  the 
lowest  level  in  a hierarchy  of  DATA.  The  attribute  UNITS  is  given  separately 
to  guarantee  explicitness  and  consistency  of  units  between  the  other 
attributes.  RESOLUTION  specifies  the  required  maximum  value  of  the  least 
significant  bit  for  the  DATA  in  units  described  in  the  UNITS  attribute. 

For  BETA  level  simulations,  the  attributes  UNITS,  MAXIMUM_VALUE, 
MINIMUMJ/ALUE  and  INITIALJ/ALUE  may  be  defined  above  the  lowest  level  in 
the  hierarchy  for  those  DATA  with  USE  BETA.  These  specifications,  however, 
are  not  meaningful  as  software  requirements. 

Clearly  the  assigned  values  of  the  attributes  INITIALJ/ALUE,  MINIMUM_ 
VALUE,  and  MAXIMUMJ/ALUE  should  be  consistent  with  the  TYPE  of  the  DATA. 

They  should  have  appropriate  numeric  values  if  the  TYPE  is  REAL  or  INTEGER. 


For  DATA  of  TYPE  ENUMERATION  or  BOOLEAN,  only  INITIALJ/ALUE  is  meaningful. 

For  enumerated  DATA,  INITIALJ/ALUE  should  be  assigned  a value  Identified  as 
legal  in  the  RANGE  attribute.  For  DATA  of  TYPE  BOOLEAN,  It  should  have  the 
value  TRUE  or  FALSE. 

3.1.9  Summary  of  Data  Segment  Concepts 

The  element  types,  relationships,  and  attributes  defined  below  constitute 


the  Data  Segment: 


ELEMENT  TYPES 


tLEMCNTiTYPEl  DATA 

C*  A single  piece  OP  INFORMATION  OR  SET  op 
INFORMATION  that  is  either  REQUIRED  in  the 
IMPLEMENTED  SOFTWARE  OR  IS  NEEDED  FOR 

descriptive  purposes,  *), 


ELEMCNTiTYPEl  ENTITY^CLASS 

e A general  category  of  OBJECTS  outside  the  data 
processing  subsystem,  the  OBJECTS  may  be  real 
or  perceived  and  are  those  in  the  environment 

ABOUT  WHICH  THE  DATA  PROCESSING  SUBSYSTEM  MUST 

maintain  information,  for  example#  an 

ENTITY.CLASS  MIGHT  BE  TARGET  OR  INTERCEPTOR, 
WHEN  THE  EXISTENCE  OF  AN  OBJECT  In  AN 
ENTITY_CLASS  IS  DETERMINED.  FILES  and  DATA  MAY 
BE  TEMPORARILY  CREATED  TO  MAINTAIN  INFORMATION 
ABOUT  IT,  *), 

slementbtypEi  entityItype 

(*  A SUBSET  WITHIN  A GENERAL  CLASS  (ENTITY_CLASS> 
OP  OBJECTS  OUTSIDE  THE  DATA  PROCESSING 
SUBSYSTEM  ABOUT  WHICH  THE  DATA  PRflCESSOR  MUST 

maintain  information,  for  example# 

£NTITv_TYPeS  WITHIN  THE  entityIclass  TARGET 
might  BE  DETECTION,  POTENTIALLY#  non. 
threatening#  threatening,  etc,  when  a 

PARTICULAR  OBJECT  IN  AN  ENtITY.CLaSS  IS 

determined  to  be  of  a specific  type#  the 

OBJECT  CAN  BE  SET  TO  THE  TYPE  AND  DATA  AND 
FILES  PERTINENT  to  objects  of  that  type 

TEMPORARILY  CREATED  TO  MAINTAIN  INFORMATION 
ABOUT  THE  OBJECT,  *), 

ElementiItypei  PILE 

(*  AN  AGGREGATION  OP  INSTANCES  OF  DATA#  EACH 

instance  op  which  is  treated  in  the  same 
hanner,  *), 


ELERENTljTYPEl 


INPUT^INTERFACE 

(*  A PORT  BETWEEN  THE  DATA  PROCESSING  SUBSYSTEM 
AND  ANOTHEP  SUBSYSTEM  (E,G.»  A RADAR)  THROUGH 
WHICH  DATA  IS  PASSEO  TO  THE  DATA  PROCESSING 
SUBSYSTEM,  AN  INPUT' INTERFACE  APPEARS  AS  THE 
FIRST  NODE  OF  ONE  AND  ONLY  ONE  R_nET 
STRUCTURE,  *). 


STRUCTURE  APPLICABILITY!  NET. 


ELEMCNTiTYPEl  MESSAGE 

(*  AN  AGGREGATION  OF  DATA  AND  FILES  THAT  PASS 
THROUGH  AN  INTERFACE  AS  A LOGICAL  UNIT,  *), 
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CLCHENTBiT  VPC  f OUTPUT-INTERFACE 

(*  A PORT  BETWEEN  THE  DATA  PROCESSING  SUBSYSTEM 

and  another  part  of  the  system  ce.g.#  a radar), 
through  which  data  is  passed  to  the  other 
subsystem,  an  output“interface  may  appear  on 
AN  R NET  or  SUBNET  STRUCTURE  AS  ThE  LAST  NODE 
OF  A PATH,  •), 

STRUCTURE  APPLICABILITY!  NET. 

ELEMENTiTYPEi  SUBSYSTEM 

(*  A PART  OF  THE  SYSTEM  (E.C..  A RAOaR)  WHICH 
COMMUNICATES  WITH  THE  DATA  PROCESSING 
SUBSYSTEM,  *), 


relationships 


RELATIONSHIP!  ASSOCIATES 

(•  identifies  which  data  and  files  come  into 
existence  when  A DATA  PROCESSING  STEP  (AN 
alpha ) either  CREATES  an  INSTANCE  of  an 
entity_class  or  SETS  The  enTity^type  of  an 
instance  OF  an  ENTITY^CLASS.  data  and  FILES 
CAN  BE  ASSOCIATED  WITH  ONLY  ONE  EnT I T Y_CL ASS , 
DATA  AND  FILES  MAY  BE  ASSOCIATED  wITH  SEVERAL 
ENTITv^TYPES  provideo  the  entityJ>ypes 
COMPOSE  THE  SAME  EN T I T YlCL ASS , DaTA  AND  FILES 
THAT  ARE  ASSOCIATED  WITH  AN  ENTlTy^TYPE  OR 
ENTITY.CLASS  May  NOT  ALSO  MAKE  A MESSAGE,  DATA 

that  is  associated  WITH  an  entityitype  or 

ENTITy_CLASS  may  NOT  ALSO  bE  CONTAINED  in  a 
FILE,  *). 

COMPLEMENTARY  RELATIONSHIP!  ASSOCIATED  ("WITH")’. 

SUBJECT  EleMENOyPEi  ENTITYjCLASS 

ENTITY^TYPE, 

OBJECT  ELEMENT  TYPE!  DATA 

FILE, 

RELATIONSHIP!  COMPOSES 

(*  IDENTIFIES  TO  WHICH  ENT I.TY*CLASS  aN  ENTITY'TyPE 
BELONGS,  an  entity.type  COMPOSES  only  one 
ENTITYJCLASS!  an  ENTITyICLaSS  IS  COMPOSED  OF  AT 
LEAST  ONE  ENTITY^TYPE,  *). 

COMPLEMENTARY  RELATIONSHIP!  COMPOSED  ("OF"). 

SUBJECT  ELEMENT.TYPEi  entity^type, 

OBJECT  ELEMENT..TYPEI  ENTITYICLASS, 


BEST  AVAILABLE  COPY 
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RELATIONSHIP!  CONNECTS  ("TO") 

(*  IDENTIFIES  WITH  WHICH  SUBSYSTEM  ThE 

inputunterface  OR  OUTPUTSJiNTERFAcE 
COMMUNICATES,  AN  INTERFACE  CONNECTS  TO  ONLY 
ONE  SUBSYSTEM,  *), 

COMPLEMENTARY  RELATIONSHIP!  CONNECTED  ("TO"). 

SUBJECT  ELEMENTlTYPEi  INPUTllNTERF ACE 

OUTPUT jlNTERFACE, 

OBJECT  ELEMENT.TYPEl  SUBSYSTEM, 

RELATIONSHIP!  CONTAINS 

(*  IDENTIFIES  THE  MEMBERS  OF  EACH  INSTANCE  IN  A 

file,  data  may  be  contained  in  Only  one  file, 

DATA  THAT  IS  CONTAINED  IN  a FILE  MAY  NOT  ALSO 
MAKE  A MESSAGE  NOR  MAY  IT  flE  ASSOCIATED  WITH  AN 

entity_class  or  entity;type.  • ). 

COMPLEMENTARY  P'LATIONSHIPI  CONTAINED  ("IN"), 

SUBJECT  ELEMEK  TYPEi  file, 

OBJECT  ELEMENT.fYPE!  DATA, 

RELATIONSHIP!  CREATES 

(#  INDICATES  THAT  THE  ALPHA  CREATES  aN  INSTANCE  OF 

the  Entity  classes),  creation  op  an  entity 
instance  in  a CLASS  OCCURS  IMMEDIATELY  at  the 
BEGINNING  of  an  ALPHA  WHICH  CREATES  the 
ENTITy.CLASS,  only  one  new  ENTITY  INSTANCE  is 
CREATED,  *). 

COMPLEMENTARY  RELATIONSHIP!  CREATED  ("BY"), 
subject  ELEHENT.TYPEi  alpha* 

OBJECT  ELEMENT.TYPEl  ENT  I T Y_CL ASS , 

RELATIONSHIP!  DESTROYS  . 

(*  INDICATES  THAT  THE  ALPHA  DESTROYS  AN  INSTANCE 
(THE  currently  SELECTED  One)  OF  ThE 
ENTITY  CLASS(ES),  identification  of  the 
INSTANCE  IS  PERFORMED  BY  A SELECT  OR  FOR  EACH 
node  on  a network,  DESTRUCTION  of  the  instance 
OCCURS  IMMEDIATELY  BEFORE  COMPLETION  of 

processing  in  the  alpha,  *), 

COMPLEMENTARY  RELATIONSHIP!  DESTROYED  ("BY"), 

SUBJECT  ELEMENT^TYPE i ALPHA* 

OBJECT  ELEMENT.TYPEl  ENTlTY_CLASS, 

RELATIONSHIP!  FORMS 

(*  INDICATES  THAT  THE  ALPHA  ESTABLISHES  THE 

message  as  the  one  to  be  passed  by  the 

CORRESPONDING  OUTPUTllNTERF ACE  (ThE 

output„interface  which  passes  the  message) 
when  THAT  INTERFACE  IS  ENCOUNTERED  ON  THE  NET, 
AN  ALPHA  MAY  FORM  SEVERAL  MESSAGES  PROVIDED 

they  are  passed  by  different 

OUTPUT_INTERFACES.  *), 

COMPLEMENTARY  RELATIONSHIP!  FORMED  ("BY"), 

SUBJECT  ELeMENT_TYPE!  ALPHA, 

OBJECT  ELEMENT.TYpE!  MESSAGE. 


3-15 


RELATIONSHIP!  INCLUDES 

(•  INDICATES  A HIERARCHICAL  RELATIONSHIP  BETWEEN 
DATA,  IP  A INCLUDES  B,  THEN  OBTAINING  A WILL 
OBTAIN  B,  *}. 

COMPLEMENTARY  RELATIONSHIP!  INCLUDED  ("IN"). 

SUBJECT  ELEMENT.TYPEl  data, 

OBJECT  ELEMENT.TYPEl  DATA, 

RELATIONSHIP!  INPUTS 

(*  IDENTIFIES  THE  DATA  AND  FILES  USED  BY  THE 
ALPHA*.  *). 

COMPLEMENTARY  RELATIONSHIP!  INPUT  ("TO")'. 

SUBJECT  ELEMENT.TYPEl  ALPHA. 

OBJECT  ELEMENT. TYPE!  DATA 

PILE, 

RELATIONSHIP!  MAKES 

(A  INDICATES  THAT  THE  DATA  OR  FILE  Ig  A LOGICAL 
component  of  THE  MESSAGE,  a data  or  FILE  may 
make  SEVERAL  MESSAGES,  data  and  FILES  THAT 
MAKE  A MESSAGE  MAY  NOT  ALSO  BE  ASSOCIATED  WITH 

an  entityJtype  or  entityJclass,  data  that 
makes  a message  may  not  also  be  contained  in  a 
F ILE , * ) , 

COMPLEMENTARY  RELATIONSHIP!  MADE  ("BY"). 

SUBJECT  ELEMENTjTYPEi  DATA 

FILE, 

OBJECT  ELEMENT.TYPEl  MESSAGE. 

RELATIONSHIP!  ORDERS 

(*  INDICATES  THAT  THE  VALUE  OF  the  data  IS  USED  TO 
ORDER  THE  INSTANCE*  OF  THE  FILE,  A FILE  MAY  BE 
ordered  by  ONLY  ONE  datai  the  data  may  NOT 
INCLUDE  OTHER  DATA  AND  SHOULD  BE  CONTAINED  IN 

the  file,  *), 

COMPLEMENTARY  RELATIONSHIP!  ORDERED  ("BY"), 

SUBJECT  ELEMENT_TVPE|  DATA, 

OBJECT  ELEMENT.TYPEl  FILE, 

RELATIONSHIP!  OUTPUTS 

(*  IDENTIFIES  THE  DATA  AND  FILES  WHOgE  VALUES  OR 
CONTENTS  ARE  MODIFIED  BY  THE  ALPHA,  *). 
COMPLEMENTARY  RELATIONSHIP!  OUTPUT  ("FROM"), 

SUBJECT  ELEMENT.TYPEl  ALPHA, 

OBJECT  ELEMENT.TYPEl  DATA 

FILE, 

RELATIONSHIP!  PASSES 

(*  IDENTIFIES  THE  LOGICAL  UNITS  OF  INFORMATION 
WHICH  ARE  PASSED  THROUCH  ThE  INTERFACE,  AN 
INTERFACE  MAY  PASS  SEVERAL  MESSAGES!  A GIVEN 
MESSAGE  MAY  BE  PASSED  THROUGH  ONLY  ONE 
INTERFACE,  *}, 

COMPLEMENTARY  RELATIONSHIP!  PASSED  ("THROUGH"), 

SUBJECT  ELEMENTjTYPEi  INPUTjlNTERFACE 

outputjinterface, 

OBJECT  ELEMENT.TYPEl  MESSAGE. 


r 


f 

i 


i 


i" 


RELATIONSHIP*  RECORDS 

(*  IDENTIFIES  THE  PARTICULAR  pATA  AND  FILES  WHICH 
ARE  TO  BE  HADE  AVAILABLE  AT  THE 
validaTiontpoint  for  performance 

EVALUATION,  *j, 

COMPLEMENTARY  RELATIONSHIP!  RECORDED  ("BY"). 

SUBJECT  ELEHENT^TyPEi  validation-point. 

OBJECT  ELEMENT.TVPEI  data 

FILE. 

RELATIONSHIP!  SETs 

(*  INDICATES  THAT  THE  ALPHA  ESTABLISHES  AN 

INSTANCE  (THE  CURRENTLY  SELECTED  ONE)  OF  AN 
ENT  I Ty— CLASS  TO  8E  OF  THf.  eNTITY^tYPE, 
IDENTIFICATION  OF  the  INSTANCE  IS  PERFORMED  BY 
A SELFCT  OH  FOR  EACH  NODE  ON  A NETWORK,  AN 
alpha  may  SET  several  ENTifY^TYPES  PROVIDED  THE 
EntITy'tyPes  do  not  compose  the  same 
ENTITy.CLASS,  the  SETTING  of  AN  ENTITY^TyPE 
OCCURS  IMMEriATELY  IN  aN  ALpH*  SUBSEQUENT  TO 
ANY  ENtITY  CREATIONS,  a), 

COMPLEMENTARY  RELATIONSHIP!  SET  ("8Y"). 

SUBJECT  ELEMENT^TYPEi  ALPHA, 

OBJECT  EIEMENT_TYPE|  ENTlTY.TYPE, 


ATTRIBUTES 


AjTRlPUTtl  InITIALIvALijE 

(•  THE  INITIAL  VALUE  A DATA  ITEM  IS  REQUIRED  TO  HAVE 

in  the  Implemented  software,  this  value  will  be 
assumed  by  the  data  item  when  it  COMES  INTO 

EXISTENCE  IN  A SIMULATION,  *)’. 

APPLICABLE  ELEMENTiTYPEl  DATA, 

VALUE  I NAMED, 

VALUE  I NUMERIC. 


ATTRlBUfEl  locality 

(*  THE  ACCESSIBILITY  AND  LIFETIME  OF  A DATA  OR 
FILE.  • >. 

APPLICABLE  ELEMENT.TyPfci  DATA 


HLE. 

value t global 

(*  GLOBAL  data  and  FILES  ARE  ACCESSIBLE  By  MORE  than 
one  RlNET  and  may  EXIST  THROUGHOUT  EXECUTION  OF  THE 
system^  data  and  files  which  are  associated  with  an 

EN?ITY_TYPe  OR  an  ENTITYlCLASS  aRE  by  DEFINITION 
GLOBAL,  *)'. 

value  I local 

<*  LOCAL  DATA  AND  FILES  ARE  ASSOCIATED  WITH  THE  R’NETS 
in  which  they  are  used  and  exist  only  during  the 

INVOCATION  OF  THE  RjNET  TO  WHICH  THEY  aRE  LOCAL, 
data  and  files  which  make  a message  are  by 
definition  LOCAL,  *), 
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AjTRlBUrEl  MAXlMUM^vALljE 

(*  THE  MAXIMUM  VALUE  A DATA  ITEM  MAY  ASSUME.  THE 
VALUE  IS  IN  THE  UNITS  STATED  jN  THE  UNITS 
ATTRIBUTE  AND  SHOULD  BE  CONSISTENT  WITH  THE  TYPE  OP 
THE  DATA,  *), 

APPLICABLE  ELEMENOyPEI  DATA. 

VALUE!  NUMERIC, 

Attribute!  minihum~value 

(«  THE  MINIMUM  VALUE  A DATA  ITEM  MAY  ASSUME,  THE 
VALUE  IS  IN  THE  UNITS  STATED  jN  THE  UNITS 
ATTRIBUTE  AND  SHOULD  BE  CONSISTENT  WITH  THE  TYPE  OP 
THE  DATA,  *), 

APPLICABLE  ELEMENOyPEI  DATA. 

VALUE!  NUMERIC, 

Attribute!  range 

(«  THE  NAMED  VALUES  THAT  CAN  BE  ASSUMED  BY  A DATA  WITH 
TYPE  ENUMERATION,  e), 

APPLICABLE  ELEMENOyPEI  DATA. 

VALUE!  TEXT 

The  allowed  values  are  separated  by  commas, 

Attribute  resolution 

(*  DESCRIBES  THE  REQUIRED  MAXIMUM  VALUE  OF  THE  LEAST 

significant  bit  for  the  data  in  units  specified  in 

THE  UNITS  ATTRIBUTE.  *)■ 

APPLICABLE  ELEMENOyPEI  DATA. 

VALUE!  NUMERIC, 


attribute!  type 

(*  the  type  for  a data  item  which  is  either 

REFERENCED  on  AN  R~NET  OR  SUBNET  OR  is  USED  IN  A 
beta  or  GAMMA  SIMULATION,  *). 

APPLICABLE  ELEMENOyPEI  DATA. 

VALUE  I REAL. 

VALUE  I ENUMERATION 

<*  the  data  item  can  assume  only  ceptain  values 
which  are  names,  the  allowed  values  for  the  data 

ITEM  ARE  SPECIFIED  IN  THE  RANGE  ATTRIBUTE.  *) , 
VALUE!  BOOLEAN, 

VALUE!  INTEGER. 


ATTRIBUTE!  UNITS 

(«  THE  ENGINEERING  UNITS  OF  THE  yALUE  OF  A DATA  ITEM 

or  the  units  in  which  the  maxihum^time  and/or 

MINIMUM.. TIME  FOR  A VALlDATlSNflPATH  ArE 

specified,  *>. 

APPLICABLE  ELEMENOyPEI  DATA 

validationIpath’. 


VALUE!  NAMED 

(*  FOR  INDIVIDUAL  PROJECTS  IT  MAY  bE  DESIRABLE  TO 

RESTRICT  THE  UNITS  WHICH  CAN  BE  USED,  IN  THAT  CASE, 

named  should  be  replaced  by  the  specific  legal 


VALUE  NAMES. 


*>. 


■I 
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AtTRXBUtEI  use 

(*  QUALIFIES  THE  USE  OF  A DATA  ITEM  IN 
SIMULATION.  • )■ 

applicable  elehenOypei  DATA, 

VALUE  I BETA 

<*  THE  DATA  ITEH  IS  T8  BE  USED  IN  FUNCTIONAL 
SIHULATIBNS  ONLY,  *). 

VALUE  I 6AHMA 

<*  THE  DATA  ITEM  IS  T6  APPEAR  IN  ANALVTIC 
SIMULATIONS  ONLY.  *). 

VALUE  I BOTH 

(*  THE  DATA  ITEM  1$  TO  BE  USED  IN  ROTH  FUNCTIONAL  AND 

analytic  simulations,  *>, 


* 
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3.2  ALPHA  SEGMENT 


k. 


The  basic  processing  steps  In  the  description  of  a set  of  functional 
requirements  are  embodied  In  the  RSL  element  type  ALPHA.  The  neutral  name 
"ALPHA"  is  used  In  order  to  avoid  any  implication  of  a software  implemen- 
tation function  (such  as  interrupt  handling).  ALPHAS  are  data  processing 
system  requirements  which  may  need  to  be  implemented  in  several  parts  of 
the  data  processing  system  for  the  sake  of  reliability,  because  of  the 
need  for  separability,  or  due  to  the  prior  existence  of  code. 

3.2.1  Executable  Descriptions 

Within  the  ALPHA  the  actual  requirement  is  represented  for  simula- 
tion purposes  with  an  "executable  description",  called  a BETA  or  GAMMA. 

The  alternatives  under  investigation  might  be  gross-level  functional 
models  of  an  ALPHA  being  evaluated  with  a functional  simulation;  these 
functional  models  are  called  BETAS.  The  alternatives  might  also  involve 
detailed  analytic  models  or  algorithms  in  an  analytic  "test-bed"  being 
evaluated  with  an  analytic  emulation;  these  latter  models  are  called 
GAMMAs. 

The  BETA  and  GAMMA  executable  descriptions  are  written  in  the  PDL  2 
or  PASCAL^  language.  The  executable  descriptions  look  like  PASCAL  pro- 
cedures with  omission  of  the  procedure  heading  and  with  augmenting  statements 
for  that  part  of  the  requirement  representing  access  to  data  hierarchies. 

All  of  the  normal  PASCAL  programming  features  and  facilities  are  available, 
except  that  all  data  that  is  not  strictly  local  to  a BETA  or  GAMMA  must  be 
declared  via  the  RSL  Data  Segment  (see  Section  3.1).  The  REVS  Simulation 
Generation  function  processes  these  executable  descriptions  to  produce 
standard  PASCAL  procedures  for  incorporation  into  the  BETA  or  GAMMA  simu- 
lation. 

3.2.2  Referencing  Date 

Communication  between  BETAs  or  GAMMAs  of  several  ALPHAS  during  simu- 
lation is  via  the  DATA  described  in  the  Data  Segment  (see  Section  3.1).  No 

^The  Texas  Instruments  Process  Design  Language  (PDL  2)  [1]  is  a PASCAL- 
based  language  supported  on  the  TI  ASC  machines  at  the  ARC  and  at  NRL. 

PDL  2 extends  standard  PASCAL  [2].  On  CDC  installations  of  REVS,  only 
standard  PASCAL  will  be  available. 


direct  communication  outside  these  defined  DATA  is  allowed,  or  the 
executable  code  in  the  simulation  would  rapidly  grow  apart  from  the  speci- 
fied requirements.  Since  a simulation  will  either  be  a beta  or  a gamma, 
communication  between  a BETA  and  a GAMMA  is  not  meaningful. 

As  described  in  the  Data  Segment,  an  ALPHA  INPUTS  and  OUTPUTS  DATA 
specifying  the  DATA  which  is  used  or  generated  by  the  ALPHA.  These  rela- 
tionships reflect  the  processing  required  of  the  ALPHA  and  thus,  to  ensure 
that  the  simulations  reflect  the  requirements,  remain  valid  for  both  BETAs 
and  GAMMAs.  This  means,  for  example,  that  if  an  ALPHA  INPUTS  DATA  A and 
B,  then  A and  B are  used  in  both  the  BETA  and  GAMMA  executable  descriptions. 
In  many  cases  it  may  be  necessary  In  a functional  simulation  for  the  BETA  to 
use  a representation  of  A and  B rather  than  the  actual  DATA  Items.  This  Is 
accomplished  by  using  a data  hierarchy.  Another  DATA  item,  say  DATA  C,  is 
defined  which  INCLUDES  DATA  A and  B and  which  has  USE  BETA  and  an 
appropriate  TYPE.  It  is  then  specified  that  the  ALPHA  INPUTS  DATA  C rather 
than  DATA  A and  B.  This  means  the  same  thing  in  a requirements  sense  as 
inputting  A and  B (since  obtaining  DATA  C obtains  DATA  A and  B),  but  in  a 
functional  simulation  DATA  A and  B will  not  actually  exist  as  variables 
but  will  be  represented  by  a single  item  C. 

DATA  specified  in  RSL  are  represented  in  simulations  as  variables  of 
the  types  assigned  by  the  RSL  attribute  TYPE.  Thus,  reference  to  DATA  from 
within  a BETA  or  GAMMA  is  via  the  RSL  name  of  the  element  consistent  with 
the  ordinary  PASCAL  reference  conventions. 

3.2.3  Accessing  Files 

FILES  consist  of  multiple  instances  of  their  constituent  parts.  In 
the  executable  code  of  the  BETA  and  GAMMA,  the  analyst  must  be  able  to 
specify  clearly  which  instance  he  wishes  to  deal  with.  Further,  he  must 
be  able  to  create  and  destroy  instances  in  a FILE.  To  accomplish  these 
manipulations,  special  operators  have  been  made  available  to  be  used  in 
writing  the  BETAs  and  GAMMAs.  These  operators  are  processed  by  the  Simu- 
lation Generation  function  to  generate  executable  PASCAL  code.  These 
extensions  are  described  below;  their  syntax  and  more  details  are  given 
in  Section  7.1.1. 

The  four  special  operators  are  CREATE,  SELECT,  FOR  EACH,  and 
DESTROY.  The  CREATE  and  DESTROY  statements  both  specify  a FILE  name. 
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The  CREATE  statement  designates  that  a new  instance  (record)  is  to  be  added 
to  the  FILE.  The  DESTROY  statement  designates  that  the  currently  SELECTed 
record  for  the  FILE  is  to  be  destroyed.  The  SELECT  involves  the  selection 
of  desired  instances  in  a FILE  by  the  application  of  a subsetting  condition, 
and  further  selection  within  this  subset  by  a FIRST  or  NEXT  criterion  to 
uniquely  identify  an  instance. 

To  explain  the  operation  of  the  FILE  SELECT,  one  may  visualize  the 
FILE  as  an  ordered  assemblage  with  a pointer  which  may  be  moved.  The 
SELECT  statement  first  causes  repositioning  of  the  pointer:  to  the  first 
instance  if  the  statement  is  a SELECT  FIRST;  or  to  the  one  following  the 
current  pointer  position  for  a SELECT  NEXT.  The  condition  (selection 
criterion)  is  then  evaluated  using  the  DATA  CONTAINED  in  the  instance 
designated  by  the  pointer.  If  the  expression  evaluates  to  TRUE,  the  SELECT 
has  found  the  desired  instance.  Otherwise  the  pointer  is  moved  to  the 
next  instance  and  the  process  repeated.  If  the  condition  is  omitted,  an 
instance  will  be  SELECTed  by  positioning  of  the  pointer  only. 

The  search  does  not  go  end-around,  it  terminates  when  the  last  instance, 
as  defined  by  the  FILE  ordering,  is  reached.  The  predefined  LOCAL  DATA  item 
REC0RD_F0UND  is  set  to  TRUE  if  an  instance  is  SELECTed  and  is  set  to  FALSE  if 
an  instance  is  not  found. 

After  a particular  record  of  a FILE  has  been  SELECTed,  all  references 
to  DATA  CONTAINED  in  the  FILE  are  assumed  to  refer  to  the  instance  of  that 
DATA  in  the  SELECTed  record.  Of  course,  another  SELECTIon  on  the  FILE  will  change 
the  Instance  that  Is  assumed  for  all  references.  The  SELECTed  record  In  a FILE 
remains  SELECTed  until  a new  SELECTion  is  made,  even  though  the  processing 
flow  may  have  passed  from  one  ALPHA  to  another.  The  SELECTion  is  local 
to  an  R_NET;  no  FILE  instances  are  SELECTed  on  the  invocation  of  an  R_NET . 

The  CREATE  and  DESTROY  accomplish  implicit  SELECTion.  After  a CREATE, 
the  newly  created  record  is  SELECTS.  The  DESTROY  destroys  the  currently 
SELECTed  record  and  does  not  SELECT  another  record. 

The  final  FILE  operator,  the  FOR  EACH,  allows  the  application  of 
processing  repeatedly  to  several  instances  in  a FILE.  The  FOR  EACH  specifies 
a condition  and  the  FILE  name,  a block  of  PASCAL  code  to  be  executed  for 
records  meeting  the  criterion,  and  an  ENDFOREACH  symbol.  The  embedded 

PASCAL  code  will  be  executed  for  each  record  meeting  the  selection  criterion. 
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The  FOR  EACH  searches  through  the  FILE  from  first  to  last  just  as  if  a 
SELECT  FIRST  followed  by  SELECT  NEXTs  had  been  written.  If  no  instances 
are  found  the  embedded  code  is  never  executed.  Since  the  FOR  EACH 
cycles  through  ell  records  in  the  FILE,  there  is  no  instance  SELECTed 
after  completion  of  the  FOR  EACH.  FOR  EACHs  may  be  nested  without  affect- 
ing the  operation  of  any  of  the  FOR  EACHs. 

3.2.4  Accessing  Entitles 

ENTITY_CLASSes,  like  FILEs,  consist  of  multiple  instances.  Instances 
to  be  processed  must  be  clearly  specified.  This  is  accomplished  by 
SELECTion  and  FOR  EACH  operations  on  the  Requirements  Networks  and  is 
described  in  Section  3.3. 

3.2.5  Operations  on  Entities  and  Messages 

The  RSL  relationships  CREATES,  DESTROYS  and  SETS  are  between  ALPHAS 
and  ENTITY_CLASSes  and  ENTITY_TYPEs . They  indicate  that  an  ALPHA  determines 
the  existence  of  an  instance  in  an  ENTITY_CLASS  (CREATES  and  DESTROYS)  and 
its  specific  ENTITY_TYPE  (SETS).  The  relationship  FORMS  between  an  ALPHA 
and  a MESSAGE  indicates  that  the  ALPHA  designates  that  the  MESSAGE  will  be 
PASSED  by  the  appropriate  OUTPUT_INTERFACE  when  the  interface  is  encountered 
subsequently  on  the  net. 

To  ensure  consistent  representation  of  the  requirements  in  a simula- 
tion, code  representing  these  actions  is  automatically  inserted  in  an 
ALPHA'S  executable  description  (BETA  or  GAMMA)  when  a simulation  is 
generated.  CREATES  and  SETS  are  performed  immediately  in  the  BETA  or 
GAMMA  — the  CREATES  being  performed  first.  DESTROYS  and  FORMS  are  per- 
formed immediately  before  exiting  a BETA  or  GAMMA  after  any  user  specified 
code. 

3.2.6  Summary  of  A1 pha  Segment  Concepts 

The  element  type  and  attributes  defined  below  constitute  the  Alpha 
Segment: 


lit*-. 
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ELEMENT  TYPE 


ElEMENT*TYPE|  ALPHA 

(*  A BASIC  PROCESSING  STEP  IN  THE  FUNCTIONAL 
REQUIREMENTS.  *). 

STRUCTURE  APPLICABILITY!  NET. 


ATTRIBUTE!  BETA 

(*  THE  PROCEDURAL  CODE  (PASCAL)  FOR  FUNCTIONALLY 
MODELING  THE  PROCESSING  STEP.  THE  CODE  IS  NOT 
PROCESSED  BY  THE  RSL  TRANSLATOR  BUT  jS  PROCESSED 
BY  THE  SIMULATION  GENERATION  FUNCTION  AND  THE 
COMPILER.  A BETA  MAY  USE  THE  SPECIAL  CREATE, 
DESTROY,  SELECT  AND  FOR  EACH  flPERAT I oNS  ON 
FILES.  *), 

APPLICABLE  ELEMENTlTYPE!  ALPHA, 

VALUE!  TEXT, 

ATTRIBUTE!  GAMMA 

(*  THE  PROCEDURAL  CODE  (PASCAL)  FOR  ANALYTICALLY 
MCOELING  A PROCESSING  STEP.  f HE  CODE  IS  NOT 
PROCESSED  BY  THE  RSL  TRANSLATOR  BUT  iS  PROCESSED  BY 
THE  SIMULATION  GENERATION  FUNCTION  AnD  THE 

compiler,  a gamma  may  use  the  special  create, 

DESTROY,  SELECT  AND  FOR  EACH  OPERATIONS  ON 
FILES. JO. 

APPLICABLE  ELEMENT_TYPE|  ALPHA, 

VALUE!  TEXT. 


3.3  REQUIREMENTS  NETWORK  SEGMENT 


The  specification  of  the  flow  of  processing  steps  in  RSL  is  called 
a Requirements  Network  or  R_NET.  Each  R_NET  details  the  response  of  the 
system  to  particular  stimuli.  It  specifies  the  sequence  of  ALPHAS  to  be 
followed  to  generate  changes  in  system  state  and  responses  to  the  environ- 
ment. When  all  of  the  required  steps  are  completed,  the  R_NET  processing 
terminates.  This  sequence  of  ALPHAs  is  specified  by  giving  a graph  model 
of  the  sequence  in  a structure  declaration  associated  with  the  R_NET. 

3.3.1  Top-Down  Flow  Specification 

RSL  has  been  designed  to  allow  the  top-down  development  of  R_NETs. 
The  engineer  may  first  specify  system  responses  in  terms  of  a few  ALPHAS 
which  state  the  general  idea  of  the  processing  necessary.  At  a later 
time,  each  of  these  ALPHAS  may  be  expanded  in  terms  of  a flow  graph  of 
lower  level  ALPHAs.  This  expansion  process  changes  the  original  ALPHA  to 
a SUBNET,  a named  processing  net  which  exists  as  a part  of  a higher-level 
net.  Therefore,  each  SUBNET  is  a single  entry-single  exit  flow;  i.e., 
there  is  one  and  only  one  point  in  the  processing  flow  that  RETURNS 
to  the  higher  level  net.  All  paths  either  rejoin  and  RETURN  at  this 
point  or  TERMINATE  processing  (alternately  ending  at  an  OUTPUT- INTERFACE). 

An  RSL  SUBNET  is  analogous  to  a macro  in  a programming  language. 

The  SUBNET  is  treated  as  though  the  flow  path(s)  in  that  SUBNET  were 
physically  inserted  into  the  higher  level  flow  path.  This  means  that  the 
data  available  to  ALPHAs  in  the  R_NET  and  to  ALPHAS  in  any  level  SUBNET 
are  identical . 

3.3.2  Enablement 

The  relationship  ENABLES  provides  the  mechanism  for  defining  the 
stimuli  which  start  processing  on  R_NETs.  An  R_NET,  which  is  the  object 
of  the  relationship,  is  ENABLED  for  processing  by  the  element  which  is 
the  subject  of  the  relationship.  Two  element  types  are  legal  as  subjects 
of  ENABLES,  corresponding  to  two  distinct  situations  which  provide  the 
stimulus  for  processing. 

The  first  situation  is  enablement  by  a stimulus  to  an  R_NET  some- 
where in  the  data  processing  subsystem.  The  element  type  EVENT  has  been 
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defined  for  this  case.  An  EVENT  must  be  specified  in  the  structure 
associated  with  an  R_NET.  The  object  R_NET  is  ENABLED  when  control 
passes  through  the  EVENT  node  on  the  R_NET  which  contains  it.  An  R_NET 
may  be  enabled  by  an  EVENT  on  its  own  structure.  Also,  the  action  of  an 
EVENT  may  be  postponed  by  use  of  the  DELAYS  relation.  The  subject  of  the 
relation  is  a DATA  item  which  specifies  how  long  ENABLEment  is  to  be 
DELAYED  when  the  object  EVENT  is  triggered.  DELAYS  and  self-ENABLEment 
allow  the  specification  of  functions  which  are  to  be  performed  periodically. 
An  R_NET  may  be  ENABLED  by  more  than  one  EVENT.  The  passage  of  control 
through  each  EVENT  will  result  in  a separate  ENABLEment  of  the  object 
R_NET.  An  EVENT  may  ENABLE  more  than  one  R_NET. 

The  other  ENABLEment  situation  concerns  stimuli  from  outside  the 
data  processing  subsystem.  In  this  case  the  subject  element  of  ENABLES 
is  an  INPUT JNTERFACE.  An  INPUT_INTERFACE,  which  is  defined  more 
completely  in  the  Data  Segment  portion  of  this  document  (Section  3.1),  pro- 
vides communication  between  the  data  processing  system  and  some  other 
SUBSYSTEM.  Data  present  at  the  INPUT_INTERFACE  is  defined  to  be  the  con- 
dition which  causes  ENABLEment  of  an  R_NET.  An  R_NET  may  be  ENABLED  by 
only  one  INPUTJNTERFACE;  an  EVENT  and  an  INPUTJNTERFACE  may  not  ENABLE 
the  same  R_NET;  and  an  INPUTJNTERFACE  may  ENABLE  only  one  R_NET. 

3.3.3  Structure 

The  flow  structure  of  an  R_NET  consists  of  two  classes  of  nodes, 
primitive  and  complex,  and  the  arcs  which  join  them.  Figure  3-2  shows 
each  of  the  RSL  structure  nodes;  also  illustrated  are  the  corresponding 
graphics  symbols.  As  can  be  seen  in  this  figure,  the  primitive  nodes  are 
single  entry  and  single  exit;  they  are  the  ones  that  specify  the  processing 
steps  and  related  ideas.  The  complex  nodes  are  multiple  entry  or 
multiple  exit  and  express  information  about  the  sequencing  of  the  primitive 
nodes. 

Five  types  of  primitive  nodes  may  be  placed  at  any  point  on  the 
structure  except  at  the  ends  of  the  processing  paths.  They  are: 

1)  ALPHAS  (defined  in  Section  3.2  of  this  document)  - the 


primitive  processing  steps. 

2)  SUBNETS  (defined  above)  - lower  level  flow  structures. 
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3)  VAL IDATION_POINTs  (see  Section  3.4)  - data  collection  points 
for  performance  measurement. 

4)  EVENTS  (defined  above)  - nodes  which  ENABLE  other  R_NETs. 

5)  SELECTS  (defined  below)  - nodes  which  identify  entity  instances. 

The  SELECT  node  identifies  an  entity  instance  to  which  the  processing 
subsequently  specified  on  the  R_NET  is  to  be  applied.  The  SELECT  designates 
an  ENTITY_CLASS  or  ENTITY_TYPE  from  which  an  entity  instance  is  to  be  chosen 
and  a condition  (selection  criterion)  involving  DATA  ASSOCIATED  with  the 
entity.  It  specifies  that  the  entity  instance  meeting  the  criterion  is  to 
be  used  in  subsequent  processing.  After  an  entity  Instance  is  SELECTed,  It 
remains  SELECTed  until  either  the  R_NET  terminates  or  another  SELECT  Is  per- 
formed on  the  same  ENTITY_CLASS  or  on  any  ENTITY_TYPE  which  COMPOSES  the 
class  containing  the  entity  instance.  After  a SELECT,  there  Is  at  most  one 
entity  selected  from  an  ENTITYjCLASS  even  though  the  SELECT  considered  only 
one  ENTITY_TYPE  composing  the  class  (l.e.,  a SELECTion  on  one  ENTITY_TYPE 
negates  any  previous  SELECTion  on  the  same  type  or  on  a different  type  of 
the  same  class). 

The  specified  condition  is  evaluated  for  each  entity  In  the  class  or 
type.  No  order  Is  specified;  consequently,  the  SELECT  is  used  when  only 
one  entity  can  meet  the  selection  criterion  or  when  any  entity  meeting  the 
criterion  is  acceptable.  On  traversing  a SELECT  node,  the  predefined  LOCAL 
DATA  item  FOUND  is  assumed  to  be  set  to  a value  depending  on  the  result  of 
the  SELECTion:  if  an  entity  meeting  the  criterion  exists  and  thus  a 
SELECTion  has  occurred,  FOUND  will  have  the  value  TRUE;  if  no  SELECTion  is 
made,  FOUND  will  have  the  value  FALSE. 

The  condition  appearing  in  the  SELECT  is  a standard  Boolean  expres- 
sion. When  SELECTing  from  an  ENTITY_CLASS,  the  condition  involves  DATA 
ASSOCIATED  with  the  ENTITY_CLASS.  When  SELECTing  from  an  ENTITY_TYPE, 

DATA  ASSOCIATED  with  either  the  ENTITY_TYPE  or  the  ENTITY_CLASS  which  is 
COMPOSED  of  the  type  is  used. 

The  sixth  type  of  primitive  node  is  the  interface,  described  in  Sec- 
tion 3.1.  An  interface  marks  the  place  in  the  R_NET  where  data  and  stimuli 
are  introduced  from  or  communicated  to  the  outside  world.  Interfaces  are 
restricted  to  being  at  the  beginning  of  an  R_NET  (for  an  INPUT_INTERFACE) 
or  at  the  ends  of  R_NET  paths  (for  an  OUTPUT_INTERFACE) . 
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The  seventh  and  eighth  types  of  primitive  nodes  also  signal  the  end  of 
a flow  path;  naturally,  they  may  be  placed  only  at  the  end  of  the  structure 
declaration  or  at  the  end  of  a flow  path  within  the  structure.  A TERMINATE 
node  means  that  all  processing  on  that  flow  path  is  ended.  It  is  not 
specified  if  an  R_NET  path  finishes  at  an  0UTPUT_I NTERFAC E . The  RETURN* 
node  means  that  the  end  of  processing  on  the  main  path  of  a SUBNET  structure 
has  been  reached  and  that  the  flow  continues  on  the  higher  level  structure 
which  references  the  SUBNET. 

The  first  of  the  three  complex  nodes,  the  FOR  EACH  node,  specifies  a repetitive 
data  structure  (an  ENTITY_CLASS,  an  ENTI7Y_TYPE,  or  a FILE),  an  ALPHA  or 
SUBNET,  and  an  optional  condition  involving  DATA  related  to  the  structure. 

The  SUBNET  or  ALPHA  is  performed  once  for  each  instance  in  the  structure 
that  meets  the  condition**  The  order  of  evaluation  is  not  specified,  so 
the  different  invocations  of  the  ALPHA  or  SUBNET  may  be  assumed  to  be  done 
in  a "don't  care  sequence".  Thus,  the  FOR  EACH  node  may  be  looked  upon  as 
an  iterative  operation  (without  sequential  implications)  over  the  repetitive 
structure  with  the  application  of  the  condition  as  a subsetting  criterion. 

(It  can  also  be  considered  as  an  AND  structure,  the  second  complex  node  to 
be  discussed  next,  with  the  number  of  branches  known  only  at  the  time  of 
invocation  of  the  FOR  EACH.)  As  stated  above  the  condition  is  optional, 
if  omitted,  the  ALPHA  or  SUBNET  is  performed  for  all  instances  in  the 
structure. 

Again,  the  condition  is  a standard  Boolean  expression.  When  the 
repetitive  structure  is  an  ENTITY_CLASS,  the  criterion  involves  DATA 
ASSOCIATED  with  the  ENTITY_CLASS.  For  an  ENTITY_TYPE,  the  DATA  used  in 
the  condition  may  be  ASSOCIATED  with  either  the  ENTITY_TYPE  or  the 
ENTITY_CLASS  which  the  type  COMPOSES.  In  the  case  of  a FILE,  the  criterion 
references  DATA  CONTAINED  in  the  FILE. 


*The  graphic  symbol  for  a RETURN  is  a A , that  for  a SUBNET  start  node  is  a V. 

**In  the  graphical  form  of  an  R_NET  structure,  the  FOR  EACH  node  is  repre- 
sented by  two  symbols:  one  to  designate  the  FOR  EACH  and  another  for  the 
ALPHA  or  SUBNET  in  the  scope  of  the  FOR  EACH  (see  Figure  3-2).  The  ALPHA 
or  SUBNET  symbol  always  immediately  follows  the  FOR  EACH  symbol. 
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Since  the  FOR  EACH  on  an  ENTITY_CLASS  or  ENTITY_TYPE  evaluates  the 
condition  for  all  entities  in  the  specified  class  or  type  and  functions  as 
a SELECTion  for  the  ALPHA  or  SUBNET,  the  FOR  EACH  node  negates  the  result 
of  any  previous  SELECT  node  for  the  pertinent  ENTITYjCLASS  or  any  ENT ITY_ 
TYPE  which  COMPOSES  the  class  --  i.e.,  after  completion  of  a FOR  EACH, 
there  is  no  entity  SELECTed  within  the  ENTITY_CLASS  which  is  the  subject 
of  the  FOR  EACH  or  which  is  COMPOSED  of  the  subject  ENTITY_TYPE.  Similarly, 
after  a FOR  EACH  on  a FILE,  no  instance  is  identified  as  SELECTed  for  the 
FILE.  (FILE  SELECTions  also  occur  within  ALPHAS  and  are  discussed  in 
Section  3.2). 

The  second  type  of  complex  node  is  the  AND  node.  This  node  has  one 
entry  arc  and  several  exit  arcs.  The  meaning  is  that  all  of  the  exit  arcs 
are  followed  but  the  order  of  processing  of  the  paths  is  not  relevant  in  a 
requirements  sense  --  in  fact,  the  arcs  may  be  followed  in  parallel  as  long 
as  the  meaning  of  the  data  is  maintained.  Thus  the  parallel  branches  of  the 
flow  graph  following  this  node  are  followed  without  regard  to  order;  they 
form  a "don’t  care  set".  The  requirements  analyst  may,  by  using  AND  nodes, 
specify  that  no  order  need  be  imposed  on  a group  of  ALPHAS. 

There  are  two  classes  of  AND  structures.  In  the  first  class,  the 
parallel  branches  do  not  rejoin;  each  of  them  ends  with  a TERMINATE  or  an 
OUTPUT_INTERFACE.  The  branches  for  this  split-off  AND  are  independent  of 
each  other  and  have  no  mutual  timing  constraints.  The  other  class  is  the 
rejoining  AND.  In  this  structure,  there  is  a virtual  AND  node  with  multiple 
entries  and  a single  exit  which  collects  all  of  the  parallel  branches.  This 
virtual  node  will  not  be  passed  until  all  of  the  branches  have  been  pro- 
cessed. In  this  sense,  it  acts  as  a synchronizing  node.  There  is  no 
syntactic  distinction  between  these  two  classes  of  AND  structures;  the 
composition  of  the  branches  determines  the  class.  Either  all  of  the 
branches  terminate  or  none  of  them  do;  a mixed  case  is  not  allowed. 

The  third  and  final  type  of  complex  node  is  the  OR  node.  It  also 
has  one  entry  and  several  exits,  but  only  one  of  the  exit  arcs  is  followed. 
The  choice  is  made  based  on  a condition  associated  with  each  arc.  The  OR 
node  and  its  accompanying  structure  represent  the  folding  together  of 
several  paths  of  processing  with  structures  which  are  identical  to  a point, 
but  differ  based  on  some  choice  criterion.  If  the  paths  differ  from  that 
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point  on,  the  OR  is  a split-off  OR.  If  the  paths  are  again  identical  at 
some  later  point,  the  branches  may  be  collected  at  a virtual  OR  node  with 
several  entries  and  one  exit.  This  structure  is  a rejoining  OR.  Again, 
mixed  rejoining  and  split-off  OR  branches  are  not  allowed. 

There  are  two  types  of  OR  nodes:  the  basic  OR  node  and  the  CONSIDER 
OR  node.  For  the  basic  OR  node  the  condition  on  each  exit  arc  of  the  node 
is  a standard  Boolean  expression  which  may  involve  DATA  elements  and 
constants.  This  condition  is  evaluated  when  the  OR  node  is  reached.  With 
general  conditions  such  as  this,  it  is  important  to  assure  that  the  choice 
of  branch  is  well-defined,  since  more  than  one  condition  may  be  true,  or 
possibly  all  of  the  conditions  may  be  false.  For  the  former  case,  the 
analyst  may  specify  an  ordinal  for  each  condition.  The  ordinal  gives  the 
position  of  that  condition  in  an  evaluation  order.  When  the  OR  node  is 
reached,  the  conditions  are  evaluated  in  the  specified  order,  and  the  first 
condition  which  evaluates  to  TRUE  specifies  the  branch  to  be  followed.  If 
the  ordinals  are  not  given,  the  lexical  ordering  of  the  conditions  ( i . e . , 
the  order  in  which  the  conditions  are  entered)  is  taken  as  the  order  of 
evaluation.  To  prevent  problems  if  all  conditions  are  false,  an  OTHERWISE 
clause  is  required  for  the  basic  OR  node.  This  clause  specifies  a branch 
which  is  followed  only  if  none  of  the  conditions  are  true. 

The  second  type  of  OR  node,  the  CONSIDER  OR  node,  allows  branching 
on  the  value  of  DATA  which  has  TYPE  ENUMERATION  (see  Section  3.1.7),  or 
branching  on  the  ENTITY_TYPE  of  the  currently  SELECTed  entity  of  a particu- 
lar ENTITY_CLASS.  With  each  branch  of  the  CONSIDER  OR  node  is  associated 
a criterion.  Each  criterion  consists  of  a single  name  or  a list  of  names 
separated  by  the  word  OR. 

DATA  with  TYPE  ENUMERATION  have  values  which  are  names.  The  criteria 
specify  which  branch  is  to  be  taken  based  on  the  value  of  the  DATA  under 
CONSIDERation.  The  legal  value  names  of  the  DATA  are  specified  in  the  RANGE 
attribute  of  DATA  (see  Section  3.1.7).  All  of  the  legal  value  names  must 
appear  once  and  only  once  in  the  branching  criteria  of  a CONSIDER  OR.  In 
order  to  prevent  confusion  of  the  value  names  with  DATA  names  which  may 
occur  in  the  basic  OR  node  branch  conditions,  DATA  items  with  TYPE 
ENUMERATION  may  be  referenced  on  a structure  only  in  CONSIDER  OR  nodes. 
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The  branch  criteria  when  an  ENTITY_CLASS  is  being  CONSIDERed  con- 
tain the  names  of  the  ENTITYJYPEs  which  COMPOSE  the  ENTITY_CLASS.  Each 
type  composing  the  class  is  referenced  once  and  only  once  in  the  branch- 
ing criteria. 

Since  the  criteria  for  a CONSIDER  OR  must  be  exhaustive,  an 
OTHERWISE  branch  is  not  allowed. 


The  element  types  and  relationships  defined  below,  along  with  the 
structure  declaration,  constitute  the  Requirements  Network  Segment. 


ELEMENT  TYPES 


ELEKENTiTYPEl  event 

(*  AN  identified  POINT  IN  the  sequence  OF 

PROCESSING  SPECIFIED  BY  ONE  OR  MOrE  R.NETS  (OR 
SUBNETS)  WHICH  CAUSES  THE  ENABLEMENT  OF  AN 
R^NET.  AN  EVENT  MAY  BE  USED  TO  SPECIFY  A 
VALIDATION  PATH.  *). 

STRUCTURE  APPLICABILITY!  NET. 

STRUCTURE  APPLICABILITY!  PATH, 

ELEMENTOTYPEi  r.net 

(*  the  order  of  logical  processing  that  must  be 

PERFORMED  by  the  data  PROCESSING  SUBSYSTEM  in 
RESPONSE  to  EXTERNAL  Or  INTERNAL  STIMULI.  THE 
PROCESSING  steps  ARE  ALPHAS  or  subnets  which 
MAY  BE  EXPANDED  TO  LOWER  LEVELS  Of  DETAIL.  IN 
adoitjon  to  processing  steps,  the  R_NET 
structure  may  contain  INTERFACES,  EVENTS, 
validation^points,  andsi  ors,  selects,  and  for 

EACH  NODES!  IT  MUST  BE  ENABLED  AND 
TERMINATED.  *). 

Ei.EMENT»TYPE|  SUBNET 

(*  A SEQUENCE  OF  LOGICAL  PROCESSING  STEPS  THAT 
MUST  BE  PERFORMED  TO  ACCOMPLISH  ThE 
requirements  op  the  next  HIGHER  NETWORK 
(SUBNET  OR  R_NET).  *), 

STRUCTURE  APPLICABILITY!  NET, 
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RELATIONSHIPS 


relationship*  delays 

<*  THE  ENABLEMENT  OF  R^NETS  BY  THE  EVENT  IS 

POSTPONED  FOR  THE  AMOUNT  Of  TIME  SPECIFIED  IN 

the  data,  only  one  data  may  delay  an  eventi 
this  data  must  not  include  other  data,  for 

SIMULATION  PURPOSES,  THE  VALUE  OF  THIS  DATA 
MUST  BE  IN  UNITS  OF  SECONDS.  *). 

COMPLEMENTARY  RELATIONSHIP!  DELAYED  ("By*), 

subject  elemenOypei  data, 

OBJECT  ELEMENT.TYPE*  EVENT, 
relationship*  enables 

(*  INDICATES  that  WHEN  THE  PROCESSING  CONTROL  FLOW 
PASSES  THROUGH  THE  EVENT  ON  AN  R*nET,  OR  WHEN 
DATA  IS  AVAILABLE  AT  THE  INPUT” INTERF ACE , Y HE 
FUNCTIONAL  PROCESSING  SPECIFIED  By  THE  RlNET 
CAN  BE  BEGUN,  AN  R*NET  MusT  BE  ENABLED  AND  CAN 
BE  ENABLED  EITHER  BY  ONE  AND  ONLY  ONE 
INPUT3INTERPACE  OR  BY  ONE  oR  MORE  EVENTS,  • ). 
COMPLEMENTARY  RELATIONSHIP*  ENABLED  ("By"), 

SUBJfCT  ELEMENT_TYPt*  event_ 

INPUT’JNTERFACE. 
object  element_type*  r_net. 
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3.4  VALIDATION  SEGMENT 


The  R_NETs,  ALPHAS,  and  DATA  concepts  of  RSL  are  used  to  describe  the 
functional  requirements  for  processing.  The  concepts  comprising  the  Vali- 
dation Segment  of  RSL  support  the  definition  of  the  performance  require- 
ments to  be  met  by  the  real-time  software. 

Two  types  of  performance  requirements  are  expressed  in  RSL:  response 
time  requirements  for  a path  of  processing,  and  accuracy  and  more  complex 
timing  relationships.  The  response  time  requirements  are  stated  separately 
because  they  apply  to  single  paths  and  are  a common  type  of  requirement. 

In  both  cases,  specific  paths  within  R_NETs  are  identified. 

3.4.1  Validation  Points 

R_NET  paths  are  identified  using  VALIDATION_POINTs . The  points  appear 
as  nodes  on  R__NET  or  SUBNET  structures  and  are  somewhat  analogous  to  test 
points  in  a piece  of  electronic  hardware.  Conceptually,  the  VALIDATION_POINT 
transfers  information  to  a recording  system  which  records  the  relevant  in- 
formation for  post-test  analysis  to  determine  whether  accuracy  and  timing 
performance  requirements  have  been  satisfied  by  the  process.  Since  the 
system  under  test  is  a data  processing  system,  the  information  transferred 
consists  of  DATA  and  FILES.  A VALIDATION_POINT  RECORDS  DATA  and  FILES; 
these  DATA  and  FILEs  are  those  necessary  to  describe  and/or  test  a per- 
formance requirement. 

For  DATA  ASSOCIATED  with  ENTITY_CLASSes  and  ENTITY_TYPEs , only  DATA 
ASSOCIATED  with  the  currently  SELECTed  entity  may  be  RECORDED.  To  RECORD 
DATA  for  more  than  one  class,  the  VALIDATION_POINT  is  placed  in  the  scope 
of  a FOR  EACH  on  the  ENTITY_CLASS  or  one  of  its  ENTITY_TYPEs . 

For  RECORDED  DATA  which  is  CONTAINED  in  a FILE,  the  DATA  values  in 
the  currently  SELECTed  (by  an  ALPHA  or  a FOR  EACH  on  a net)  record  in  the 
FILE  are  RECORDED.  If  the  FILE  is  also  RECORDED,  then  the  specified  DATA 
is  RECORDED  from  each  record  of  the  FILE. 

There  is  no  explicit  output  from  a VALIDATION_POINT.  As  stated 
above,  a model  for  the  use  of  the  DATA  is  that  they  are  recorded  in  a 
data  file  to  be  used  in  a post-processing  mode  to  determine  whether  the 
performance  requirements  have  been  met.  Thus  for  each  traversal  of  a 
VALIDATION_POINT,  a recording  is  generated  which  contains  the  DATA  and 
FILES  RECORDED  by  the  VALIDATION  POINT. 


3.4.2  Validation  Paths 


The  individual  paths  through  an  R_NET  which  are  of  interest  in  des- 
cribing performance  requirements  are  stated  in  RSL  as  VAL IDAT I0N_PATHs . 

The  path  structure  of  a VAL IDAT I0N_PATH  is  primarily  a sequence  of 
VALIDATION_POINTs  on  a single  R_NET.  A path  thus  described  must  correspond 
to  a route  through  an  R_NET;  it  is  illegal,  for  instance,  to  specify  that 
a path  exists  between  VALIDATION_POINTs  which  are  on  parallel  branches  of 
an  AND  or  OR  structure.  If  all  paths  between  two  nodes  are  to  be  included 
in  the  requirements,  then  the  requirements  engineer  need  merely  refrain 
from  noting  any  VALIDATION_POINTs  between  the  nodes.  Therefore,  if  all 
paths  through  an  R_NET  are  included,  just  the  starting  and  ending  VALIDA- 
TI0N_P0INTs  need  to  be  noted.  For  example,  consider  the  R_NET  structure 
shown  in  Figure  3-3.  If  both  paths  through  the  net  are  to  be  included, 
then  a VALIDATION_PATH  may  be  defined  using  only  VALIDATION_POINTs  VI  and 
V3.  Conversely,  if  only  one  path  through  a multiple  path  R_NET  is  to  be 
considered,  sufficient  VALIDATION_POlNTs  must  be  specified  so  that  the 
desired  path  is  uniquely  identified.  In  the  example,  VALIDATION_POINT  V 2 
would  be  included  in  the  VAL IDAT I0N__PATH  definition  in  order  to  designate 
the  path  through  ALPHAS  A,  C and  D. 

In  many  instances,  timing  and  accuracy  requirements  span  more  than 
one  R_NET.  RSL  provides  a mechanism  to  extend  the  VALIDATION_PATH  to 
cover  more  than  one  R_NET,  if  an  EVENT  on  the  first  R_NET  ENABLES  the 
second  R_NET.  EVENTS  are  then  placed  on  PATHS  so  that  the  flow  of  pro- 
cessing to  the  R_NETs  which  are  ENABLED  by  the  EVENT  may  be  followed. 

Thus  the  PATH  structure  of  a VALIDATION_PATH  contains  VALIDATION_POINTs 
and  EVENTS  as  nodes. 

For  performance  requirements  which  apply  to  processing  performed  by 
more  than  one  path  in  an  R_NET  in  multiple  executions  or  by  paths  on 
different  R_NETs,  RSL  allows  the  definition  of  the  VALIDATION_PATHs 
separately  and  the  definition  of  a relationship  between  the  performance 
requirements  and  the  VALIDATION_PATHs  as  explained  In  Section  3.4.4. 

3.4.3  Stimulus-Response  Timing  Requirements 

Timing  requirements  can  be  imposed  along  a VAL IDAT I0N_PATH  through 
use  of  the  attributes  MINIMUM_TIME  and  MAXIMUM_TIME.  The  points  for 
starting  and  stopping  the  stimulus-response  timing  measurement  are  the 
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start  and  termination  of  the  R_NET  path  identified  by  the  PATH  structure 
of  the  VALIDATION_PATH.  If  the  VALIDATION_PATH  specifies  multiple  paths 
through  the  R_NET,  the  timing  requirements  are  interpreted  to  mean  that 
all  of  these  R_NET  paths  must  meet  the  timing  constraints. 

Also  associated  with  the  stimulus-response  timing  is  the  attribute 
UNITS,  which  specifies  in  what  units  of  time  the  MINIMUM_TIME  and  MAXIMUM 
TIME  attributes  are  to  be  interpreted.  The  reason  for  separation  of  the 
UNITs  attribute  from  the  two  value  attributes  is  the  same  in  this  segment 
as  it  is  in  the  Data  Segment  — to  guarantee  the  explicitness  and  con- 
sistency of  units  between  the  minimum  and  maximum  values. 


3.4.4  Analytic  Performance  and  Non-Stimulus-Response-Timing  Requirements 

Analytic  performance  requirements  and  certain  timing  requirements 
can  not  be  stated  as  simply  as  stimulus-response  timing  requirements.  Two 
reasons  make  this  so:  a combination  of  several  DATA  and  a complex  trans- 
formation may  be  needed  to  state  the  requirements;  and  the  requirements 
may  be  a function  of  DATA  from  more  than  one  VALTDATION_PATH.  Therefore, 
the  requirement  cannot  be  stated  as  a property  of  a VALIDATION_PATH  but 
is  stated  as  a PERFORMANCE_REQUIREMENT.  A PERFORMANCE_REQUIREMENT  CON- 
STRAINS one  or  more  VALIDATION_PATHs. 

A PERFORMANCE_REQUIREMENT  has  an  attribute  TEST  which  defines  the 
requirement  as  an  executable  PASCAL  function  with  a Boolean  value.  The  in- 
formation available  in  the  TEST  is  all  of  the  DATA  and  FILES  RECORDED  by 
the  VALIDATION_POINTs  appearing  on  the  VALIDATION_PATHs  CONSTRAINED  by  the 
PERFORMANCE_REQUIREMENT.  Special  commands  in  the  TEST  identify  how  the 
data  is  to  be  extracted  from  the  recording  of  the  validation  point  informa- 
tion, and  the  PASCAL  code  defines  the  computations  necessary  to  test  the 
satisfaction  of  the  requirement.  The  result  of  the  TEST,  which  may  examine 
a number  of  individual  DATA  against  several  Independent  criteria.  Is  the 
value  assigned  by  the  TEST  to  the  PERFORMANCE_REQUIREMENT  function.  The 
name  of  this  function  Is  the  PERFORMANCE  REQUIREMENT  name. 


A VALIDATION_POINT  can  appear  only  once  on  the  nets  but  can  appear 
on  many  paths.  Conceptually,  each  time  the  processing  reaches  a VALIDATION 
POINT  on  a net,  a RECORDING  is  generated  consisting  of  all  DATA  RECORDED 
by  the  VALIDATION_POINT.  A VALIDATION_POINT  can  RECORD  a FILE;  in  which 
case  DATA  is  extracted  for  each  record  in  the  FILE.  The  same  DATA  and 


FILES  may  be  RECORDED  by  many  VALIDATIONPOINTs . 


J 
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Thus,  DATA  referenced  in  a TEST  must  be  uniquely  identified  by 
VALIDATION_POINT,  by  RECORDING,  and  by  record  in  a FILE  and  a FILE  must 
be  identified  by  VALIDATION_POINT  and  RECORDING.  The  approach  adopted  to 
establish  uniqueness  is  analogous  to  that  used  in  the  remainder  of  RSL  for 
DATA  and  FILES  ASSOCIATED  with  entities  and  for  DATA  CONTAINED  in  FILEs. 

The  main  difference  is  that  all  DATA  and  FILE  names  appearing  in  the  TEST 
are  prefixed  by  the  name  of  the  VALIDATION_POINT  which  RECORDED  the  DATA 
or  FILE  to  be  used.  The  two  names  are  separated  by  a decimal  point.  (Thus, 
to  refer  to  DATA  (or  FILE)  A RECORDED  by  VALIDATION_POINT  VI,  the  identifiei 
VI .A  is  used  in  the  TEST.) 

The  special  operators  available  in  TESTs  for  identifying  a particular 
RECORDING  are  the  RETRIEVE  and  FOR  EACH.  These  have  the  identical  meaning 
as  the  SELECT  and  FOR  EACH  on  FILEs  written  in  BETAs  and  GAMMAs  described 
in  Section  3.2.3.  After  a RETRIEVE  operation,  the  Boolean  variable 
RECORD ING_F0UND  will  have  the  value  TRUE  if  a RECORDING  which  meets  the 
retrieval  criterion  was  located;  otherwise,  RECORD  I NG_F0UND  will  have  the 
value  FALSE.  The  RECORDING  RETRIF.VFd  remains  available  until  the  next 
RETRIEVE  or  FOR  EACH  is  encountered  on  the  same  VALIDATION_POINT.  The 
FOR  EACH  in  a TEST  has  the  same  meaning  as  the  FOR  EACH  statement  In  BETA/GAMMA 
code;  the  code  encompassed  by  the  DO  and  ENDFOREACH  in  the  FOR  EACH  opera- 
tion is  executed  in  sequence  for  each  RECORDING  meeting  the  retrieval 
criterion.  A SELECT  and  FOR  EACH  on  FILEs  are  also  available  for  writing 
TESTs  and  have  this  same  interpretation.  The  syntax  for  each  of  the 
special  TEST  operators  is  presented  in  Section  7.1.2. 

3.4.5  Summary  of  Validation  Segment  Concepts 

The  element  types,  relationship,  and  attributes  defined  below  constitute 
the  Validation  Segment: 

ELEMENT  TYPES 

element jtype * performance.requirement 

c*  AN  ANALYTIC  PERFORMANCE  REQUIREMENT  OR 

NON-STIMULUS-RESPONSE  TIMING  REQUIREMENT  WHICH 
IS  TO  BE  MET  BY  THE  DATA  PROCESSING 
SUBSYSTEM,  *), 
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ELEMENT!(jTYPE|  VALIDATlON^PATH 

<*  A PATH  OF  PROCESSING  OyER  WHICH  QUANTITATIVE 
VALIDATION  TESTING  WILL  be  PERFORMED,  a path 
IS  SPECIFIED  USING  VaLIDATiSN.POInTS  and 
EVENTS  AND  MUST  CORRESPOND  TO  A RflUTE  THROUGH 

an  r_net  or  through  r^nets  connected  BY 
EVENTS,  *>, 

ElEHENT>ITYPEi  VALIDATlONlPOlNT 

(*  A LOGICAL  POINT  IN  THE  PROCESSING  SPECIFIED  BY 
AN  R.NET  OR  SUBNET  AT  WHICH  DATA  MUST  BE 
OBTAINABLE  IN  THE  IMPLEMENTED  SOFTWARE  IN  ORDER 
TO  VALIDATE  THAT  THE  PERFORMANCE  REQUIREMENTS 
HAVE  BEEN  FULFILLED,  *). 

STRUCTURE  APPLICABILITY!  NET, 

STRUCTURE  APPLICABILITY  I PATH. 


RELATIONSHIP 


RELATIONSHIP!  constrains 

(*  IDENTIFIES  TO  WHICH  VAl!DatION*PatH(S)  THE 
PERFORMANCElREQUlREMENT  APPLIES,  *), 
COMPLEMENTARY  RELATIONSHIP!  CONSTRAINED  ("BY"), 

SUBJECT  ELEMENT^TYPEi  PERFORMANCEIREQUIReMENT, 

OBJECT  ELEMENT^ TYPE  I VALIOATION'PATH, 


ATTRIBUTES 


Attribute i maximum~time 

(*  THE  MAXIMUM  TIME  THAT  CAN  BE  TAKEN  TO  TRAVERSE  THE 
VALIDATlONlPATH,  THE  TIME  IS  SPECIFIED  IN  THE  UNITS 
STATED  IN  THE  UNITS  ATTRIBUTE!  *). 

APPLICABLE  ELE*ENOvPEI  VALIDATION.>ATh. 

valuei  numeric, 

ATTRIBUTE!  MINIMUM_>IME 

<4  THE  MINIMUM  TIME  THAT  CAN  BE  TAKEN  To  TRAVERSE  THE 
VALIDATlONlPATH,  THE  TIME  IS  SPECIFIED  IN  THE 
UNITS  DESIGNATED  BY  THE  UNITS  ATTRIBUTE,  *). 
APPLICABLE  ELEMENOyPE!  VALIDATlONlPATH'. 

VALUE!  NUMERIC, 


AfTRlBUfEl  TEST 

(«  PROCEDURAL  CODE  (PASCAL)  WHICH  DEFINES  THE 

COMPUTATIONS  NECESSARY  TO  TEST  THE  SATISFACTION  OF 
A PERFORMANCE-REQUIREMENT  USInG  DATA  RECORDED  BY 
VALIDATION*POlNTS.  THE  CODE  jS  NOT  PROCESSED 
BY  THE  R3L  TRANSLATOR  BUT  IS  PROCESSED  BY  THE 
SIMULATION  GENERATION  FUNCTION  AND  THE  COMPILER. 

A TEST  CONTAINS  SPECIAL  RETRIEVE  AND  FOR  EACH 
OPERATIONS  TO  IDENTIFY  VALIDatION^POINT  RECORDINGS 
AND  MAY  USE  SELECT  AND  FOR  EacH  OPERATIONS  TO 
ACCESS  RECORDED  FILES,  *), 

APPLICABLE  ELEMENOYPE!  PERFORMANCE^REQuIREMENf , 

VALUEI  TEXT. 


3-42 


3.5  MANAGEMENT  SEGMENT 


r 

■ £ 


, — . 


t 


f- 

i 


f 


Concepts  necessary  to  support  the  disciplined  management  of  a require- 
ments engineering  project  are  contained  in  the  Management  Section  of  RSL. 

These  concepts  are  broadly  defined  and  provide  a framework  of  useful  infor- 
mation which  can  be  adapted  to  many  types  of  project  management. 

3.5.1  Configuration  Management 

The  size  of  modern  software  projects  dictates  that  close  track  be 
kept  of  changes  to  the  system  at  all  levels,  from  requirements  to  code. 

To  support  configuration  management,  information  must  be  maintained  about 
the  nature  and  author  of  each  change  to  the  system.  In  RSL,  this  informa- 
tion can  be  maintained  about  each  element  of  the  requirements  description. 

Updates  to  each  element  in  the  ASSM  provide  the  change  history,  including 
the  individual's  identity,  through  the  ENTERED_BY  attribute;  and  the  ASSM 
itself  provides  the  current  state  of  the  element.  The  attribute 
COMPLETENESS  (which  can  be  associated  with  any  element)  provides  a means 
tor  the  requirements  engineer  to  identify  how  close  his  entry  is  to  its 
final  form.  If  he  is  merely  noting  initial  ideas,  he  can  give  the 
attribute  the  value  INCOMPLETE.  The  other  attribute  values  (CHANGEABLE 
and  COMPLETE)  indicate  increasing  finality  of  the  requirements. 

3.5.2  Traceabil ity 

The  output  of  the  software  requirements  engineering  effort  should  be 
directly  traceable  upward  to  the  originating  requirements  in  the  system 
requirements  documentation.  Data  on  these  originating  requirements  are 
given  in  RSL  through  the  use  of  the  element  type  ORIGINATING  REQUIREMENT. 

Elements  which  are  traced  from  an  ORIGINATING_REQUIREMENT  are  linked  to 
it  by  the  TRACES  relationship. 

The  TRACES  relationship  may  be  used  to  assess  the  impact  of  a change 
to  an  ORIGINATING  REQUIREMENT.  In  many  cases,  though,  the  ORIGINATING^ 

REQUIREMENTS  are  interrelated  in  a hierarchical  manner,  such  that  lower 
level  requirements  add  detail  to  more  global  higher  level  requirements. 

This  hierarchy  is  reflected  by  the  relationship  INCORPORATES  between 
ORIGINATING_REQUIREMENTs. 

The  traceability  downward  to  different  versions  of  the  system  is 
also  facilitated  by  the  element  type  VERSION  and  the  relationship  IMPLEMENTS. 
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Any  element  of  the  requirements  can  thus  be  identified  as  being  IMPLEMENTED 
by  only  a few  VERSIONS  or  by  all  of  them. 

Some  requirements  may  need  to  be  implemented  precisely  in  the  real- 
time software  in  order  that  the  data  processing  system  will  function 
correctly,  even  though  they  are  not  directly  traceable  to  system  require- 
ments. The  degree  to  which  an  element  is  artificial,  therefore,  is 
associated  with  its  degree  of  traceabil ity,  but  not  perfectly.  For  this 
reason  ARTIFICIALITY  is  a separate  attribute  that  can  be  associated  with 
any  element  in  the  stated  requirements. 

3.5.3  Decisions 

Although  some  ORIGINATING_REQUIREMENTs  can  be  directly  allocated  to 
lower  levels  (and  TRACED  to  those  lower  levels),  many  ORIGINATING_REQUIRE- 
MENTs  must  be  combined  with  other  information  in  order  to  take  them  to 
lower  levels.  This  may  occur  because  the  ORIGINATING_REQUIREMENT  was 
ambiguous  or  incomplete,  because  many  alternative  interpretations  of  the 
requirement  may  exist  and  an  assumption  or  choice  must  be  made  to  proceed, 
or  because  a literal  interpretation  of  the  ORIGINATING_REQUIREMENT  would 
cause  conflict  with  other  ORIGINATING_REQUIREMENTs  or  with  common  sense. 

In  each  case,  the  requirements  engineer  must  make  some  considered  decision 
about  how  to  proceed;  the  decisions  and  the  considerations  (as  well  as  the 
initial  problem)  must  be  documented  so  that  other  requirements  engineers 
know  why  derived  (as  opposed  to  allocated)  decisions  have  been  made.  In 
addition,  an  ORIGINATING_REQUIREMENT  may  change,  and  documented  decisions 
will  need  reconsideration;  they  can  be  reconsidered  far  more  rapidly  and 
efficiently  than  undocumented  decisions. 

The  element  type  DECISION  is  provided  to  enable  the  requirements 
engineer  to  note  these  derived  requirements.  It  is  related  to  one  or  more 
ORIGINATING_REQUIREMENTs  or  other  DECISIONS  and  to  the  resulting  require- 
ments through  the  relationship  TRACES.  It  has  attributes  of  PROBLEM, 
ALTERNATIVES,  and  CHOICE  which  provide  the  needed  documentation. 

3.5.4  Source  Material 

The  element  type  ORIGINATING_REQUIREMENT  does  not  reflect  the  or i jin 
of  the  requirements .e. , whether  It  appeared  In  a system  specification,  an 
interface  specification  or  some  other  document.  In  addition  to  requirements 
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derived  from  ORIGINATING_REQUIREMENTs,  there  may  be  some  which  arise  from 
conditions  documented  in  background  material.  If  this  background  infor- 
mation changes,  the  requirements  must  also  change;  therefore,  the  background 
source  should  appear  in  the  requirements  description  and  should  be 
explicitly  traceable  to  elements  which  it  influences.  The  element  type 
SOURCE  exists  to  fill  these  needs.  A SOURCE  DOCUMENTS  elements  which 
depend  on  material  in  the  SOURCE. 

3.5.5  Synonyms 

Alternative  or  shortened  names  for  elements  of  a requirements  descrip- 
tion may  be  entered  by  defining  an  element  of  type  SYNONYM.  The  SYNONYM  is 
linked  to  the  original  element  by  the  relationship  EQUATES.  An  original 
name  may  be  EQUATED  to  any  number  of  SYNONYMS,  but  each  SYNONYM  EQUATES  to 
one  and  only  one  element. 

3.5.6  Unstructured  Information 

Additional  commentary  or  descriptive  information  about  an  element 
which  does  not  fit  into  the  context  of  the  relationships  or  attributes 
which  are  applicable  to  that  element  may  be  included  in  the  attribute 
DESCRIPTION.  The  value  for  DESCRIPTION  is  a text  string  which  has  no 
predefined  structure.  A requirements  engineer  may,  therefore,  include  in 
DESCRIPTION  an  English  language  explanation  or  summary  of  the  element. 

In  addition  to  the  capability  of  including  unstructured  commentary 
about  the  normally-structured  requirements,  RSL  provides  a means  for 
documenting  requirements  which  do  not  fit  into  the  patterns  established 
by  the  standard  element  types.  This  type  of  requirement,  for  example 
one  which  says  that  the  implementation  language  shall  be  FORTRAN,  may  be 
included  as  an  UNSTRUCTURED_REQUIREMENT  in  the  requirements.  Since  an 
UNSTRUCTURED_REQUIREMENT  is  an  element,  all  of  the  normal  management 
relationships  such  as  TRACES  or  EQUATES  are  applicable  to  it.  This  allows 
the  inclusion  of  the  unstructured  information  in  the  management  process. 

3.5.7  Summary  of  Management  Segment  Concepts 

The  element  types,  relationships,  and  attributes  In  the  Management 
Segment  are  presented  below: 
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ElEMENT^TYPE  t 


ElEMENT*TYPE| 


«er 


ELEMENT  TYPES 


DECISION 

£*  A CHOICE  OR  INTERPRETATION  THAT  HaS  BEEN  MADE 
IN  ORDER  TO  ESTABLISH  FUNCTIONAL  aND/OR 

performance  requirements  based  on  one  or  more 
originating_requirements,  this  means  that  the 

LOWER  LEVEL  REQUIREMENTS  ARE  A RESULT  OF 
DERIVATION,  NOT  SIMPLY  ALLOCATION’.  *), 

ORIGINATING.REQUIREMENT 

(*  A HIGHER  LEVEL  REQUIREMENT  FROM  WHICH  LOWER 
LEVEL  REQUIREMENTS  (THOSE  EXPRESSED  IN  THE  RSL) 

are  traceable,  *>, 


ELEMENTiTYPEl  source 

(*  source  or  AUXILIARY  MATERIAL  FOR  REQUIREMENTS, 

I ,E, , ORIGINATING  POINT  F 8R  ONE  OR  MORE 
ORIGlNATING.REQUIREMENTS,  DOCUMENTATION  of 
TRADEOFF  STUDIES,  OR  BACKGROUND  MATERIAL  FOR 
REQUIREMENTS  ELEMENTS,  *>. 

ElEMENTBTYPEi  synonym 

(•  A SYNBNYM  is  AN  ALTERNATE  name  that  CAN  Be  USED 
IN  PLACE  OF  THE  PRIME  NAME  OF  AN  ELEMENT,  IT 
IS  USED  AS  AN  ABBREVIATION  IN  MOST  CASES,  BUT 
MAY  Be  USED  for  OTHER  REASONS,  NflTEl  IN  THE 

rsl  definitions  of  relationships  and 

ATTRIBUTES,  "ALL"  ALWAYS  IMPLIES  "ALL  EXCEPT 
SYNONYM",  *}. 


ElementStypei  unstructuredIrequirement 

(*  A REQUIREMENT  THAT  MUST  BE  PASSED  TO  THE 
SOFTWARE  DESIGNER  BUT  THAT  DOES  NOT  FIT  INTO 

the  structured  framework  provided  by  rsl,  this 
element  might  be  USED  BECAUSE  the 
requirement  in  question  is  too  UNCOMMON  to 
justify  DEFINITION  of  a new  type  OF  element,  a 

NEW  RELATIONSHIP,  OR  a NEW  ATTRIBUTE,  (AN 

example  of  an  unstructuredIrequirement  might 

be  PRECLUSION  OF  USING  A MULTIPROCESSOR  WITH 
ASSOCIATIVE  MEMORY,)  *), 


ElEMENTBTYPEi  VERSION 

(*  THE  AGGREGATION  OF  REQUIREMENTS  THAT  ARE  TO 
APPLY  AS  A UNIT  TO  THE  DATA  PROCESSING 
subsystem  at  a particular  time,  loop:i, 
L00P_2,  ETC,,  ARE  VERSIONS,  AS  IS  AN  IOC 
SYSTEM,  *), 
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RELATIONSHIPS 


RELATIONSHIP!  DOCUMENTS 

(*  the  source  material  provides  auxiliary 

INFORMATION  about  OR  is  The  ORIGINATING  point 
for  the  object  element,  *5', 

COMPLEMENTARY  RELATIONSHIP!  DOCUMENTED  (nBY"). 

SUBJECT  ELEMENT.TYPEi  SOURCE, 

OBJECT  ELEMENT.TYPEl  ALPHA 

DATA 

DECISION 

entity^class 

ENTITY.TYPE 

event 

FILE 

INPUT^INTERFACE 

MESSAGE 

ORIGINATING  REQUIREMENT 
eUTPUONTERFACE 

PERFORM ANCE.REQUIREMENT 

r.net 

subnet 

subsystem 

UN3TRUCTURED_REQUIReMENT 

VALIOATION'PATH 

validation_point 

VERSION, 

RELATIONSHIP!  EQUATES  ("TO") 

(*  DEFINES  AN  ALTERNATE  name  for  an  ELEMENT,  The 
object  of  equates  is  CALLED  the  PRIME  name, 
the  subject  name  can  be  used  for  input  to  the 
assm,  but  all  RELATIONSHIPS,  attributes,  AND 
structures  so  defined  ARE  ACTUALLY 
CHARACTERISTICS  of  THE  prime  name'.  *). 
COMPLEMENTARY  RELATIONSHIP!  EQUATED  ("TO"), 

SUBJECT  ELEMENT_TYPE|  synonym, 

OBJECT  ELEMENT.TYPEl  ALPHA 

DATA 

decision 

ENTITY^CLASS 

entity^type 

EVENT 

FILE 

INPUUINTERFACE 

MESSAGE 

ORIGINATING~REQUIREmENT 
OUTPUT'-'INTERFACE 
PERFORMANCE  REQUIREMENT 

r_net 

SOURCE 

SUBNET 

SUBSYSTEM 

UNSTRUCTUREDlREQUlREMENT 

VALIDATlON>ATH 

VALI0ATI0N_P0INT 

VERSION, 


J 
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RELATIONSHIP!  IMPLEMENTS 

C*  DEriNES  the  VERSION(S)  TO  which  The  ELEMENT 
APPLIES.  #). 

COMPLEMENTARY  RELATIONSHIP!  IMPLEMENTED  ("BY"). 

SUBJECT  ELEMENT^TYPEi  ALPHA 

data 

DECISION 

entityjclass 

ENTITYjTYPE 

EVENT 

PILE 

INPUTllNTERFACE 

MESSAGE 

originating^requirement 

OUTPUTJINTERFACE 

PERFORMANCEIREQUIREMENT 

rInet 

SUBNET 

SUBSYSTEM 

UNSTRUCTUREDlREQUlREMENT 

VALIDATION^PATH 

VALIDATION.POINT, 

OBJECT  ELEMENT.TYPEl  VERSION, 

RELATIONSHIP!  INCORPORATES 

(*  INDICATES  A HIERARCHICAL  RELATIONSHIP  BETWEEN 
originating.requirements,  THE  SCOPE  OF  THE 
SUBJECT  (HIGHER  LEVEL)  ORIgINAT INgIREQUIREMENT 
INCLUDES  THE  OBJECT  (LOWER  LEVEL) 
ORIGINATINGIREQUIREMENT.  *). 

COMPLEMENTARY  RELATIONSHIP!  INCORPORATED  ("IN")’. 

SUBJECT  ELEMENTITYPEi  ORIGINATINGIREQUIREMENT, 

OBJECT  ELEMENT.TYPEl  ORIGINATINGIREQUIREMENT, 
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RElATIflNSHJPi  TRACES  ("TO") 

(*  IDENTIFIES  THE  ELEMENTS  (L8WER  LEVEL 

REQUIREMENTS)  TO  8R  FR8M  WHICH  THE  HIGHER 
LEVEL  REQUIREMENT  (ORIGINatING“REqUIREMENT  8R 
DECISION)  HAVE  BEEN  ALLOCATED  OR  DERIVED,  ft). 
COMPLEMENTARY  RELATIBNSHIPI  TRACED  ("FROM"), 

SUBJECT  ELEMENT_TYPE|  DECISISN 

ORIGINATING1REQUIREMENT, 

OBJECT  ELEMENT.TYPEl  ALPHA 

DATA 

DECISION 
entity'class 
ENTITY! TYPE 
EVENT 
FILE 

input_interface 

MESSAGE 

OUTPUT^ INTERFACE 
PERFORM ANCE_REQU I REmENT 

r_net 

SUBNET 

SUBSYSTEM 

unstructured^requ I REMENT 

VALI0ATI8N>ATH 

validation_point 

version, 

ATTRIBUTES 

ATTRIBUTE!  ALTERNATIVES 

(«  THE  ALTERNATIVES  THAT  HAVE  BEFN  CONSIDERED  T8 
RESOLVE  A PROBLEM  RESULTING  In  A DECISION,  *), 
APPLICABLE  ELEMENTjTyPEI  DECISION, 

VALUE!  TEXT. 


Attribute  » artificiality 

(*  THE  DEGREE  OF  FLEXIBILITY  ALLOWED  INI  IMPLEMENTING 
THE  ELEMENT  IN  THE  SOFTWARE,  *), 

APPLICABLE  ELEMENTiTYPEl  ALPHA 

DATA 

entity^class 

entity.type 

event 

FILE 

INPUT.INTERFACE 

MESSAGE 

outputIinterface 

R_net 

subnet 

validation'path 

validayion_point. 

VALUE  I ARTIFICIAL 

(ft  THE  ELEMENT  HAS  BEEN  DEFINED  FOR  EXPLANATORY  OR 
SIMULATION  PURPOSES  IN  THE  REQUIREMENTS  STATEMENT 
AND  NEED  NOT  BE  PRESENT  IN  THE  SOFTWARE,  ft), 

valuei  validation 

(ft  THE  ELEMENT  IS  NECESSARY  FOR  PERFORMANCE 

REQUIREMENTS  EVALUATION  BUT  IS  NOT  REQUIRED  IN  THE 
OPERATIONAL  SOFTWARE.  <o. 

VALUEI  IMPlEMENT^PRECISELY 

(ft  THE  ELEMENT  MUST  BE  IMMPLEMENTEO  In  THe  SOFTWARE 
EXACTLY  as  defined,  o. 

VALUE!  IMPlEMENOPPROXIMATELY 

(ft  THE  ELEMENT  MUST  BE  IMPLEMENTED  IN  THE  SOFTWARE, 
but  the  precise  implementation  is  left  to  the 

PROCESS  DESIGNER,  ft) , 

ATTRIBUTE!  choice 

(ft  THE  ALTERNATIVE  SELECTED  TO  SOLVE  A PROBLEM 

leading  to  a decision,  the  RATIONALE  for  the 
choice  should  be  included  here.  *>. 

APPLICABLE  ELEMENTiTYPEl  DECISION, 

VALUEI  text. 
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attribute i completeness 

(*  THE  DECREE  T 8 WHICH  THE  DEFINITION  Of  An  ELEMENT  IS 
IN  FINAL  FORM,  a). 

APPLICABLE  ELEMENOvPEl  ALPHA 

data 

DECISION 

entity'class 

entity_ttpe 

EVENT 

FILE 

INPUT.INTERFACE 

MESSACE 

ORIGINATING'REQuIREMENt 

OUTPUT^INTERFace 

PERFORMANCE“REQuIREMENt 

R.NET 

SOURCE 

SU6NET 

SUBSYSTEM 

unstructuredIrequirement 

VALIDATIONlPATH 

VALlDATIONlPOlNT 

VERSION, 

VALUE!  CHANGEABLE 

c*  although  All  relationships,  attributes,  and 

STRUCTURES  MAY  BE  DEFINED  FOR  THE  ELEMENT,  SOME  OF 

them  will  probably  be  changed,  INFORMATION  about 
THE  ELEMENT  IS  BELIEVED  TO  BE  CORRECT,  BUT  IS 
SUBJECT  TO  CHANGE,  a), 

VALUE!  INCOMPLETE 

(A  THE  DEFINITION  OF  THE  ELEMENT  IS  KNOWN  TO  BE 
INCOMPLETE'.  THEREFORE,  EVEN  If  RELATIONSHIPS, 

attributes,  and  structures  are  stated,  the  element 

DEFINITION  is  STILL  INCOMPLETE,  *), 

VALUE!  COMPLETE 

(a  the  DEFINITION  OF  THE  ELEMENT  SHOULD  Bf  ASSUMED  TO 
BE  COMPLETE  AND  WILL  PROBABLY  not  CHANGE,  *), 
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Attribute i description 

(*  ANY  FREE  FORM  TEXTUAL  MATERIAL  DESCRIBING  THE 
ELEMENT,  *). 

APPLICABLE  ELEMENOYPEl  ALPHA 

DATA 

DECISION 
ENTITY'CLASS 

entity_type 

EVENT 
FILE 

INPUT.INTERFACE 
MESSAGE 

ORIGINATING^REQuIREMENt 

cutputIinterface 

PERFORM ANCE^REQuIREMENt 
r.net 

SOURCE 
SUBNET 
SUBSYSTEM 

unstructuredIrequirement 
validation,path 
VALIDATI0n_P0Int 
VERSION, 

value  I text, 

AjTRlBUTEl  ENTEREDjBY 

(*  THE  IDENTITY  OF  THE  LAST  PERSfiN  TO  ENTER 
INFORMATION  ABOUT  THE  ELEMENT.  O. 

APPLICABLE  ELEMENTZTyPEI  ALPHA 

DATA 

DECISION 
ENTITY^CLASS 
ENTITY.TYPE 
EVENT 
FILE 

INPUT.INTERFACE 
MESSAGE 

ORIGINATING£REQuIREMENt 

cutputIinterface 

PERFORM ANCE"REQuIREMENt 

r.net 
souRce 

SUBNET 
SUBSYSTEM 

unstructuredIrequirement 
validation'path 
validation.point 

VERSION, 

value  I TEXT. 
attributEi  problem 

u the  problem  that  has  led  to  the  need  for  a 

DECISION.  *>. 

APPLICABLE  ELEMENTZTyPEI  DECISION, 

VALUE  I TEXT. 
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4.0  CONTROLLING  REVS 

REVS  is  a unified  collection  of  software  composed  of  functions  that 
contribute  in  different  ways  to  the  development  of  requirements.  (The 
capabilities  of  REVS  and  the  functions  which  provide  them  are  summarized 
in  Section  2.0.)  The  user  controls  REVS  using  the  REVS  Control  Language 
(RCL).  In  general,  the  user  input  to  REVS  consists  of  a continuous  stream 
of  RCL  commands  which  activate  the  various  functions  and  direct  them  to 
perform  certain  operations.  The  functions  have  individual  RCL  commands 
for  their  control;  in  the  case  of  the  RSL  translation  and  RSL  extension 
(RSLXTND)  functions  these  commands  consist  of  RSL.  Thus  the  input  stream 
to  REVS  can  be  depicted  simply  as  the  following: 

Activation  of  function  1 

-j  Commands  to  function  1 

Activation  of  function  2 

Commands  to  function  2 


Activation  of  function  n 

-j  Commands  to  function  n 

where  functions  1 through  n refer  to  any  of  the  REVS  functions. 

Activation  of  a REVS  function  is  controlled  by  the  REVS  Executive. 

It  is  always  active  from  initiation  to  termination  of  REVS  execution 
regardless  of  the  individual  REVS  functions  which  are  activated  throughout 
an  execution.  The  activation  of  a REVS  function  is  requested  by  user 
command  to  the  Executive.  Other  commands  to  the  REVS  Executive  are  avail- 
able to  control  the  general  operation  of  REVS.  Most  of  these  may  appear 
anywhere  in  the  input  stream  including  within  the  input  to  individual 
functions  where  they  will  be  intercepted  and  executed  by  the  Executive. 
Thus  the  user  input  commands  to  REVS  can  be  categorized  into  the  following 
types : 
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t Executive  Control  Statements  which  activate  REVS  functions 
and  direct  the  operational  characteristics  of  REVS. 

• Function  Control  Statements  which  are  received  by  the 
Executive  and  routed  to  the  activated  function  which  pro- 
cesses each  statement  and  performs  the  desired  operations. 

This  organization,  as  illustrated  in  Figure  4-1,  allows  complete 
flexibility  in  the  type  of  operations  that  can  be  performed  in  a single 
execution  of  REVS.  The  Executive  Control  Statements  are  described  in  this 
section  and  permit  the  user  to  activate  the  REVS  functions,  to  control  the 
input  of  information  to  REVS,  cause  mode  changes  in  the  operation  of  REVS, 

control  the  content  and  disposition  of  REVS  output,  and  terminate  the 

execution  of  REVS.  The  Function  Control  Statements  and  their  use  are 

described  in  subsequent  sections  of  this  document  (Sections  5 through  8). 

REVS  Operating  Modes 

REVS  has  two  modes  of  operation,  termed  off-line  and  on-line.  In 
the  off-line  mode,  the  user  inputs  are  made  through  the  system  input  stream 
which  usually  originates  on  cards.  In  the  on-line  mode,  communication 
between  the  user  and  REVS  is  interactive  through  an  ANAGRAPH  keyboard -display 
console. 

Executive  Control  Input  Format 

The  input  format  of  the  Executive  Control  Statements  is  the  same  in 
the  off-line  or  on-line  modes  and  requires  that  each  statement  be  solely 
contained  on  one  line,  that  only  one  statement  per  line  occur,  and  that 
no  other  information  precede  the  statement  on  the  line.  Any  information 
following  the  statement  on  the  same  line  is  treated  as  commentary.  The 
syntax  of  each  of  the  REVS  Executive  Control  Statements  is  presented  in 
this  section  along  with  a description  of  the  resulting  action  by  REVS. 

The  syntax  is  presented  in  extended  Backus-Naur  Form  (BNF).  Readers 
unfamiliar  with  BNF  should  read  Appendix  A before  proceeding  (the  syntax 
of  all  RCL  and  RSL  is  presented  throughout  the  text  in  this  notation). 
Appendix  C contains  the  complete  syntax  for  the  Executive  Control  Statements, 
In  both  BNF  and  In  the  form  of  syntax  diagrams. 

Executive  Messages 

The  REVS  Executive  will  output  messages  to  the  user  containing 
information  about  actions  of  the  Executive.  These  messages  are  documented 


r 

in  Appendix  C.  The  only  error  diagnostic  output  by  the  Executive  is  when 
Function  Control  Statements  appear  in  the  input  stream  where;  Executive 
Control  Statements  are  expected.  This  can  occur  when  the  user  enters 
Function  Control  Statements  without  a REVS  function  being  active  or  when 
a function  terminates  prematurely  before  processing  all  of  its  inputs. 

There  is  no  concept  of  a syntactic  or  semantic  error  in  an  Executive  Control 
Statement.  If  the  Executive  does  not  recognize  a statement  or  the  statement 
is  out  of  context,  the  Executive  will  assume  it  to  be  a Function  Control 
Statement. 
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4.1  SELECTING  A REVS  FUNCTION 


At  the  start  of  a REVS  execution  no  function  is  active.  The  FUNCTION 
statement  is  used  to  specify  to  the  REVS  Executive  which  function  to 
activate.  The  syntax  of  the  statement  is: 

[FUNCTION]  function-name. 

In  the  statement,  function-name  is  defined  as  one  of  the  following: 


Function  Name 

REVS  Function 

RSL 

RSL  Translation  (requirements  transla- 
tion) 

RNETGEN 

Interactive  R-Net  Generation 

RADX 

Requirements  Analysis  and  Data  Extrac- 
tion 

SIMGEN 

Simulation  Generation 

SIMXQT 

Simulation  Execution 

SIMDA 

Simulation  Data  Analysis 

RSLXTND 

RSL  Extension  Translation 

The  FEND  statement  is  used  to  explicitly  terminate  an  activated  REVS 
function.  The  syntax  of  the  statement  is: 

FEND. 

An  active  REVS  function  may  also  be  terminated  implicitly  by  entry 
of  another  FUNCTION  statement,  by  change  of  the  operating  mode  (a  GO  state- 
ment changes  the  mode,  see  Section  4.3),  and  by  termination  of  REVS  execu- 
tion (see  STOP  statement.  Section  4.5). 

Implicit  termination  applies  to  all  of  the  REVS  functions  except 
RNETGEN.  The  RNETGEN  function  has  special  features  that  are  applicable 
only  in  the  on-line  operating  mode  and  special  control  is  required  to 
terminate  this  function.  This  is  described  in  Section  5.2. 


4.2  CONTROLLING  INPUT 


The  primary  source  of  input  for  REVS  is  determined  by  the  operating 
mode.  When  operating  on-line,  the  user  communicates  interactively  with 
REVS  by  way  of  the  ANAGRAPH  console  keyboard  and  trackball.  In  the  off- 
line mode,  the  user  inputs  are  made  through  the  system  input  stream.  In 
either  mode,  the  user  may  control  the  filtering  of  the  input  for  Executive 
Control  Statements  and  may  direct  the  Executive  to  temporarily  use  an 
alternate  source  of  input. 

4.2.1  Avoiding  Executive/Function  Statement  Conflicts 

Occasionally,  the  content  of  a Function  Control  Statement  might  have 
the  appearance  of  an  Executive  Control  Statement.  (For  example,  a line 
image  in  an  RSL  text  string  might  begin  with  keywords  and  punctuation  which 
form  a legal  Executive  command.) 

The  user  may  direct  the  Executive  to  enter  a transparent  data  mode, 
thus  avoiding  misinterpretation  of  Input,  for  the  current  Input  medium  by  using 
the  TRANSPARENT  statement.  This  statement  has  the  form: 

TRANSPARENT  string. 

where  the  string  contains  from  one  to  eight  characters.  These  may  be  any 
characters  except  blank  and  period. 

Upon  entry  of  a TRANSPARENT  statement,  no  further  examination  for 
Executive  Control  Statements  in  subsequent  input  is  made  until  an  image  is 
encountered  which  starts  with  the  specified  string.  The  terminating  image 
is  logged,  but  is  not  treated  as  input  by  REVS. 

If  the  TRANSPARENT  statement  is  encountered  in  an  alternate  input 
source  (an  ADDFILE,  see  below)  the  transparency  will  be  observed  until  the 
transparency  string  is  encountered  or  until  the  end  of  file  on  the  ADDFILE 
is  reached. 

4.2.2  Designating  an  Alternate  Input  Source 

The  ADDFILE  statement  is  used  to  cause  REVS  to  accept  input  from  a 
specified  file.  The  syntax  of  the  statement  is: 

ADDFILE  [TRANSPARENT]  access-name. 

The  access  name  is  the  name  of  a file  and  is  limited  to  eight  alpha- 
numeric characters  on  the  ASC.  The  specified  file  Is  read  In  Its  entirety  as 
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though  It  were  Inserted  In  the  primary  Input  stream  In  place  of  the  ADDFILE 
statement. 


All  Executive  commands  are  valid  within  the  file,  except  another 
ADDFILE  statement.  Should  a GO  command  (see  Section  4.3)  be  placed  in  the 
file,  the  GO  operation  is  performed  and  the  ADDFILE  command  stays  in  effect 
until  all  inputs  are  read  from  the  file.  The  TRANSPARENT  option  to  the 
ADDFILE  statement  causes  suppression  of  the  examination  of  the  file  for 
Executive  Control  Statements. 


* 


4.3  SELECTING  REVS  OPERATING  MODE 
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As  stated  previously,  REVS  is  either  operated  off-line  or  on-line  via 
the  ANAGRAPH  color  console.  When  REVS  is  initially  executed,  the  operating 
mode  Is  off-line.  The  GO  command,  which  has  the  following  syntax,  is  used 
to  change  the  operating  mode. 

[ONLINE  1 

OFFLINE  [ONLY],  [display-remark] 

OPPOSITE] 

An  example  of  this  statement  is: 

GO  ONLINE.  JOE  USER  — PHONE  837-2400. 

The  keywords  within  the  GO  command  determine  the  new  operating  mode. 

ONLINE  means  that  the  ANAGRAPH  console  will  be  enabled  and  the  next  input 
to  REVS  will  be  from  there.  OFFLINE  means  that  the  ANAGRAPH  will  be 
disabled  and  the  next  input  to  REVS  will  be  from  the  system  input  stream. 

(Note:  If  a GO  statement  is  entered  requesting  the  same  mode  as  the 
current  mode,  this  statement  will  be  treated  as  a Function  Control  State- 
ment by  the  Executive.)  The  OPPOSITE  option  causes  the  operating  mode  to 
change  from  on-line  to  off-line,  or  from  off-line  to  on-line,  depending  on 
the  current  mode.  The  OPPOSITE  option  is  assumed  if  no  option  is  specified. 

The  ONLY  option  causes  an  irrevocable  change  to  the  specified  mode.  If 
another  GO  statement  is  entered  subsequent  to  the  ONLY  option,  it  will 
terminate  the  execution  of  REVS  (i.e.,  it  will  be  interpreted  as  a STOP 
statement,  see  Section  4.5).  See  Section  10  for  the  installation 
dependencies  of  this  feature. 

When  entering  the  on-line  mode,  the  display  remark  portion  of  the  GO 
statement  is  output  as  an  on-line  identification.  It  is  displayed  on  the 
ANAGRAPH  with  the  TRW  logo  when  a console  is  ready  for  use  and  should  con- 
tain sufficient  information  to  identify  and  locate  the  user  requesting  the 
consol e. 

When  operating  in  the  on-line  mode,  the  user  communicates  Interactively 
with  REVS  by  way  of  the  ANAGRAPH  console  keyboard  and  trackball.  The  key- 
board consists  of  a panel  containing  a typical  set  of  alphanumeric  characters 
which  the  user  may  key  in  when  the  keyboard  has  been  enabled  for  Input.  A 

j ] 
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short  red  horizontal  cursor  will  be  displayed  when  the  keyboard  has  been 
enabled.  The  keyboard  ENTER  key  is  depressed  to  terminate  each  line  of 
input  and  transfer  it  to  REVS.  The  trackball  consists  of  a movable  white 
cursor  operated  by  a hand-rotated  ball  and  an  entry  key  at  the  right  of 
the  console.  This  facility  provides  the  user  the  capability  to  select 
(input)  any  coordinate  position  on  the  face  of  the  CRT.  The  trackball  is 
available  for  input  when  the  white  cursor  is  blinking.  By  rotating  the 


trackball,  thus  moving  the  white  blinking  cursor  to  any  desired  position 
on  the  CRT,  and  subsequently  depressing  the  trackball  entry  key,  the  user 
inputs  the  selected  point  to  REVS. 

When  the  logo  appears  on  the  screen  with  the  user's  on-line  identifi- 
cation, the  enter  key  next  to  the  trackball  is  depressed  to  start  operating 
REVS.  A display  will  then  appear  on  the  screen  as  depicted  in  Figure  4-2. 
The  lowest  line  of  the  screen  is  the  REVS  input  area,  the  line  above  it  is 
the  echo  of  the  last  line  entered  and  the  third  line  is  the  REVS  status 


display.  The  uppermost  part  of  the  screen  (with  heavy  green  border)  is  the 
area  where  output  lines  are  displayed  for  viewing.  As  REVS  generates  out- 
put, the  page  display  will  wrap  over  itself  from  top  to  bottom  with  a red 
line  underlining  the  last  line  displayed.  This  permits  continual  visibility 
of  portions  of  the  previous  output  (except  when  interrupted  by  use  of  the 
RNETGEN  function). 


The  status  line,  annotated  in  blue  by  REVS,  has  five  display  fields 
to  show  the  current  status  of  REVS.  The  first  variable  is  the  name  of  the 
currently  activated  function  or  REVSEXEC  if  no  function  is  activated.  The 
second  variable  displayed  is  the  current  REVS  input  file  name.  This  will 
be  $0NLINE$  to  indicate  the  on-line  keyboard,  except  when  input  has  been 
diverted  through  an  ADDFILE  statement,  in  which  case  it  will  be  the  access 
name  of  the  file  being  read.  The  third  variable  displayed  is  the  output 
routing  status  which  is  set  by  the  OUTPUT  statement  (see  Section  4.4)  and 
indicates  whether  output  lines  are  being  displayed  on-line  and/or  off-line. 
The  fourth  variable  is  the  logging  resolution  status,  and  indicates  ALL 
or  EXECRCL  according  to  the  last  LOG  statement  (see  Section  4.4).  The 
final  field  is  the  transparency  indicator  which  displays  the  required 
transparency  terminator  string  when  in  the  transparent  mode. 
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4.4  CONTROLLING  OUTPUT 

There  are  two  primary  output  files  generated  by  REVS.  The  first  is 
an  Execution  Log  (REVS.LOG)  of  the  activities  that  took  place  during  the 
execution  of  REVS.  The  second  file  contains  the  output  generated  by  each 
function  that  was  executed  and  is  identified  as  REVS. OUT. 

4.4.1  Controlling  the  Logging  Resolution 

The  type  of  information  that  is  placed  in  REVS.LOG  is  controlled  by 
the  LOG  statement  which  has  the  following  syntax: 

106  Eexecrcl]  ' 

The  normal  information  output  to  REVS.LOG  is  Executive  Control  State- 
ments. This  information  is  identical  to  that  provided  when  the  EXECRCL 
option  is  selected  or  when  a LOG  statement  with  no  option  is  input.  The 
ALL  option  causes  both  Executive  Control  Statements  and  Function  Control 
Statements  to  be  logged. 

An  example  of  REVS.LOG  is  presented  in  Figure  4-3.  Each  line  is 
coded  F,  X,  or  M to  respectively  denote  a Function  Control  Statement,  an 
Executive  Control  Statement,  or  a message  issued  by  REVS.  Also  identified 
for  each  control  statement  is  the  input  source,  either  $0NLINE$  for  the 
ANAGRAPH,  REVSIN  for  the  system  input  stream,  or  the  access  name  for  an 
ADDFILE. 

4.4.2  Controlling  the  Routing  of  Function  Output 

The  OUTPUT  statement  is  used  to  control  the  routing  of  primary  output 
(file  REVS. OUT)  from  the  REVS  functions.  The  syntax  of  the  statement  is: 


OUTPUT 


ONLINE 

OFFLINE 

BOTH 

IMPLIED 


The  initial  routing  is  IMPLIED,  i.e.,  output  is  sent  to  the  off-line 
printer  when  operating  in  the  off-line  mode  and  to  the  interactive  console 
when  in  the  on-line  mode.  The  OFFLINE  option  directs  REVS  to  only  use  the 
off-line  printer  regardless  of  the  operating  mode.  The  ONLINE  option 
directs  REVS  to  only  use  the  interactive  console  for  subsequent  output.  If 
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Figure  4-3  REVS.LOG  Example  Listing 
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the  OUTPUT  ONLINE  option  is  selected  when  operating  off-line,  the  user 
will  not  receive  any  output  from  REVS.  The  BOTH  option  directs  subsequent 
output  to  be  routed  by  REVS  to  both  the  interactive  console  (when  in  on- 
line mode)  and  the  off-line  printer.  An  example  of  a REVS. OUT  listing  as 
it  appears  on  the  printer  is  shown  in  Figure  4-4. 

4.4.3  Controlling  Pagination 

The  user  has  the  option  to  perform  page  control  of  the  REVS. OUT  file 
with  the  NEWPAGE  statement. 


NEWPAGE 


OFFLINE 

ONLINE 

BOTH 

JMPLIED. 


[off! ine-page-titl ing-remark] 


An  example  of  this  statement  is: 

•NEWPAGE.  START  INPUTS  FOR  ENTITY  CHANGES. 

The  selection  of  the  OFFLINE  option  causes  the  printer  to  skip  to  the 
top  of  the  next  page  and  to  display  the  offline-title  (which  is  limited  to 
60  characters).  The  ONLINE  option  causes  the  screen  to  be  cleared  and  the 
next  output  line  to  appear  at  the  top  of  the  screen.  The  offline-title  has 
no  effect  on  the  on-line  display.  The  BOTH  option  makes  both  of  the  above 
actions  occur.  When  no  option  is  specified  or  when  the  IMPLIED  option  is 
specified,  the  action  that  is  taken  is  determined  by  the  current  output 
routing. 

4.4.4  Displaying  Information  On-Line 


When  a page  display  is  completed  during  on-line  operation,  the  user 
is  presented  the  following  response  prompting  message  at  the  bottom  of  the 
screen: 

CONTINUE,  INTERRUPT,  OUTPUT  OFFLINE,  NONSTOP. 


One  of  the  options  contained  in  this  statement  is  selected  via  a 
trackball  entry  to  control  subsequent  actions  on  the  output  displayed  by 
REVS.  The  CONTINUE  option  causes  the  next  page  of  output  to  be  displayed. 

The  INTERRUPT  entry  causes  a long  display  to  be  truncated  if  the  RADX 
function  Is  activated.  If  Input  Is  being  read  from  an  ADDFILE,  an  INTERRUPT 
entry  will  terminate  the  reading  of  the  ADDFILE.  An  OUTPUT  OFFLINE  selection 
causes  the  current  display  and  subsequent  displays  to  only  be  routed 
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xx  ooo  revs  baseline  version  s io*,  cdate=05/'13/77,  time=io«<u 122) 
rsl. 


XX  Ooi 
MODIFY 

remove 

INSERT 


FUNCTION  rsl  initiated.  ********************«************* 

performance' requirement  radiated "po^eR, 
test, 

TEsTl 
"Const 

RaDIATEdIP0WER_LImITs5,0)  (*  TEMPORARY  REPLACEMENT  FOR  CTBD)  *) 
VaR 

RaDAR_>owFR»  REAL; 

INTERVAL!  REAL! 
begin 

RADI  ATED_P0WER;  = TRUE> 

RETRIEVE  FIRST  RECORDING  FOR  STARTING-POINT; 

for  each  radar_command_output_point  recording 
do 

RADarIpO«ER:=o'.o; 

INTERVAL !=R ADAS  command  OUTPUT'’pOImt,TRANSmIT~START; 

FOR  EACH  RADAR  ‘Command  OUTPUT "POINT  RECORDING- 

SUCH  THAT  ( (RADAR'COMMAND^OUTPUT  point, TRANSHIT^START<  = 
INTERvALM,0)_AND 

( R AD AR"C ON n AND" OUTPUT  pO I NT , TR ANSM I T~ST ART>  = 
INTERVAL)) 

00 

select  first  record  from  starting  point, waveform_table 
such  that  (Radar_command^output.  point, radar_type=- 
STARTING_POINT.WF_namE)> 

IF  RECORD.FOUND  THEN 

RADAR_P0WER!sRADAR  POWE'Rt 

STARTIngIPOINT.hFICHARaCTERISTICSj 

ENDFOREACHI 

IF  {RADAR2P0WER>RAD1ATEd1P0wER"lIMIt)  then 
RadIATEDJpOweRisFaLSE; 

ENDFORfaCH 
EnD»". 

MOblFY  SUBSYSTEM  sspermrl, 
remove  TRACED  from, 

TLS  "DPSPr  SUBSECTION  5_2S  FUNCTIONAL'REQUIREmENTS, 
delete  SUBSYSTE“  SSPERMRL, 

MOolFY  SUBSYSTEM  SSF'ERmfl, 

INSERT  TRACED  from, 

TLs"DPSPR^SUbSECTI1N_j..2-’5:FUNCTI0NAL;REQUlREMENTS, 

MODIFY  DAT  a 0 1 _W I NDO w_D A T A . 

INSERT  INPUT  TO  ALPHA  SET_lOST, 

MOolFY  OATa  DOmIT. 

INSERT  INPUT  to  alpha  SET_LOST, 

MODIFY  data  XMIt  'START, 

INSERT  INPuT  TO  ALPHA  PICK  COMMAND, 

MOolFY  data  DiRTn'ERROR_REPORT, 

INSERT  use  both. 

MOolFY  DATA  RANGeImaRk_INFORMATiON, 
insert  use  beta. 

MOolFY  data  REASON_FOR  TRANSMISSION  FAILURE, 

INSERT  USE  BOTH, 

MODIFY  DAT*  RECEIVEIINFORMaTICN, 

insert  use  beta, 

XX  Oo2  function  rsl 
stop. 


COMPLETED. 


XX  0 07  REVS  COMPLETED!  NORMAL  TERMINATION, 

Figure  4-4  REVS. OUT  Example  Listing 
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off-line  until  changed  by  an  OUTPUT  control  statement.  The  NONSTOP  option 
causes  continuous  display  of  REVS  output  lines,  without  a pause  after  each 
page  is  displayed.  This  process  continues  until  the  user  is  prompted  for 
more  input  or  until  the  enter  key  on  the  trackball  is  pressed,  in  which 
case  the  NONSTOP  mode  is  discontinued. 
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4.5  TERMINATING  EXECUTION  OF  REVS 


The  STOP  statement  is  used  to  terminate  the  execution  of  REVS.  The 
statement  has  the  following  syntax: 

STOP  • [display  remark] 

This  statement  can  be  entered  either  in  the  on-line  or  off-line  mode. 
When  entered  on-line,  the  display  remark  is  written  as  a terminating  message 
on  the  final  REVS  ANAGRAPH  display.  If  neither  the  JOB  or  STEP  option  is 
specified,  the  STEP  option  is  assumed.  Also,  an  actual  end  of  file  on  the  REVS 
primary  input  stream  implies  STOP  STEP.  The  STEP  option  causes  termination 
of  REVS  and  its  job  step,  but  allows  normal  execution  of  any  remaining 
job  steps.  The  JOB  option  causes  the  REVS  step  and  all  subsequent  steps  to 
be  cancelled. 
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5.0  BUILDING  A REQUIREMENTS  DATA  BASE 


REVS  provides  two  functions  for  establishing  and  maintaining  a require- 
ments data  base.  The  primary  one,  the  RSL  translation  function,  accepts 
RSL  statements  and  enters,  modifies,  or  deletes  requirements  data  base  in- 
formation as  specified  by  these  statements.  The  RSL  syntax  for  defining, 
modifying,  and  deleting  entries  in  the  data  base  and  examples  illustrating 
the  use  of  RSL  are  presented  in  Section  5.1. 

The  Interactive  R-Net  Generation  (RNETGEN)  function  augments  the 
capabilities  of  tne  RSL  translation  function  by  allowing  the  user  to  enter 
and  modify  data  base  structures  in  a two-dimensional  graphic  form.  The 
RNETGEN  function  also  provides  the  capability  to  establish,  either  auto- 
matically or  under  user  control,  graphics  coordinate  data  for  structures 
entered  in  the  form  of  RSL.  The  operation  and  use  of  RNETGEN  is  described 
in  Section  5.2. 

The  basic  unit  of  requirements  as  stated  in  RSL  is  the  element.  The 
user  designates  elements  by  unique  names  and  establishes  their  meaning  in 
the  requirements  by  stating  their  attributes,  relationships  and  structures. 
REVS  imposes  certain  restrictions  on  the  selection  of  names  for  the  require- 
ments elements.  The  user  should  not  use  the  keywords  appearing  in  the  RSL 
and  RCL  syntax;  in  addition,  if  the  requirements  are  to  be  simulated,  the 
user  should  not  use  as  element  names  the  keywords  of  PASCAL.  The  keywords 
for  RSL,  RCL,  and  PASCAL  are  listed  in  Appendix  D.  When  simulating 
requirements,  REVS  also  requires  that  certain  element  names  be  unique  In  a 
limited  number  of  characters.  These  restrictions  are  Installation  dependent 
and  are  detailed  In  Section  10. 
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5.1  ENTERING  REQUIREMENTS  IN  RSL  (RSL  FUNCTION) 

This  section  describes  the  use  of  the  RSL  function  to  enter  require- 
ments stated  in  the  Requirements  Statement  Language  (RSL).  There  are  three 
types  of  statements,  called  RSL  commands,  which  the  user  can  input  to 
define  new  elements,  modify  existing  elements,  and  delete  elements.  Two 
additional  commands  allow  for  changing  the  name  and  the  element  type  of 
an  element.  These  five  commands  are  presented  and  illustrated  in  the 
following  subsections.  The  command  syntax  presented  is  expressed  in  the 
extended  Backus-Naur  Form  (BNF)  explained  in  Appendix  A.  The  complete  RSL 
syntax  from  which  these  rules  were  extracted  is  presented  in  Appendix  D,  in 
both  BNF  and  syntax  diagram  forms. 

General  information  that  applies  to  all  commands  input  to  the  RSL 
function  and  an  explanation  of  the  output  from  the  RSL  function  are  provided 
below. 

RSL  Input  Specifications 

The  following  rules  summarize  the  input  format  accepted  by  the  RSL 
function.  These  rules,  some  of  which  are  given  in  greater  detail  in 
Appendix  B,  together  with  the  syntax  summarized  in  Appendix  C,  give  a 
complete  input  specification  for  the  RSL  function. 

• Each  RSL  statement  is  terminated  by  a period  that  is  not  con- 
tained within  a comment  or  text  string. 

• Only  the  first  72  characters  of  each  input  line  are  significant, 
all  other  characters  are  ignored. 

• All  names  have  a maximum  length  of  60  characters.  The  first 
character  in  a word  must  be  a letter  or  an  underscore;  remain- 
ing characters  must  be  letter^,  underscores,  or  digits. 

• All  numbers  are  in  standard  PASCAL  form  (see  Appendix  B). 

• All  names  and  numbers  are  terminated  by  one  or  more  blanks, 
or  punctuation  marks  (an  end  of  input  record  is  equivalent 
to  a blank) . 

• A comment,  a sequence  of  characters  beginning  with  (*  and 
ending  with  *),  nay  only  be  used  where  specified  in  the  RSL 
syntax . 

• A text  string,  a sequence  of  characters  beginning  and  ending 
with  double  quotes,  may  only  be  used  where  specified  in  the 
RSL  syntax. 
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• The  comma,  colon,  and  semicolon  are  optional  punctuation  marks 
that  are  equivalent  to  a blank. 

• Relation  optional  words  may  appear  anywhere  in  the  input  and 
will  be  ignored. 

RSL  Output  Specifications 

For  each  input  line,  the  RSL  function  will  output  the  following  on 
REVS. OUT: 

• An  echo  of  the  72  significant  characters,  a vertical  bar 
("|"),  and  the  remaining  characters  of  the  input  line  (the 
characters  to  the  right  of  the  vertical  bar  are  ignored  by 
the  RSL  function). 

• If  an  error  was  detected  in  the  input  line,  an  additional 
line  will  be  output.  For  each  error  detected  an  up-arrow 
("t"),  followed  by  an  error  number  will  be  output.  These 
error  numbers  and  their  associated  meanings  are  listed  in 
Section  5 of  Appendix  D.  If  two  or  more  errors  are  detected 
at  a symbol,  only  one  up-arrow  will  be  output  and  the  error 
numbers  will  be  separated  by  commas. 

In  addition  to  the  standard  output  described  above,  if  any  errors 
were  detected  by  the  RSL  function,  the  following  message  will  be  produced 
on  the  REVS.LOG  file: 

TT  001  NUMBER  OF  TRANSLATION  ERRORS  = XX 
where  XX  is  the  number  of  errors  detected. 

There  are  a few  cases  in  which  the  RSL  function  may  not  be  able  to 
recover  from  an  error.  This  will  normally  occur  only  if  there  are  machine 
errors  or  severe  errors  in  the  RSL  input,  or  if  the  ASSM  or  required  input 
files  DONNEES  and  RSLDICT  are  missing  or  unusable.  If  any  of  these  occur, 
the  RSL  function  will  output  the  words  "FATAL  ERROR"  followed  by  one  of  the 
fatal  error  diagnostics  given  for  error  numbers  600  through  606  in  Section  5 
of  Appendix  D.  The  following  message  will  also  be  placed  in  the  REVS.LOG 
file: 


TT  002  FATAL  ERROR  IN  TRANSLATION. 

5.1.1  Defining  a New  Element 

The  explicit  definition  of  a new  element  consists  of  a declaration 
of  the  element,  optionally  followed  by  a series  of  element  definition 
sentences  which  declare  attribute  values,  relationships,  and  a structure  or 
path  for  the  element.  The  syntax  for  a new  element  definition  is: 
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[DEFINE]  element-type-name  element-name  [comment]. 

4 [ INSERT]  <element  definition  sentence>j>n 

As  shown  in  the  syntax,  the  word  DEFINE  is  optional  in  a new  element 
definition.  Its  use  is,  however,  recommended.  If  DEFINE  is  used  and  the 
specified  element  name  is  currently  defined  in  the  ASSM  an  error  will  be 
reported.  If  DEFINE  is  not  used  the  existing  element  will  be  modified  with- 
out notification  to  the  user.  The  word  INSERT  is  also  optional  preceding 
each  element  definition  sentence  and  may  be  used  to  improve  the  readability 
of  the  input.  The  omission  of  the  word  INSERT  has  no  affect  on  the  inter- 
pretation of  the  input. 

There  are  four  types  of  element  definition  sentences:  the  attribute, 
relation,  path,  and  structure  declarations.  These  declarations  are  discussed 
in  subsections  below  following  the  discussion  of  the  new  element  declaration. 
Another  type  of  new  element  definition,  termed  an  implicit  definition,  occurs 
whenever  a previously  undefined  element  is  introduced  within  a relation,  path, 
or  structure  declaration.  This  implicit  declaration  is  discussed  separately 
in  Section  5.1 .1 .6. 

The  top-level  syntax  for  an  explicit  new  element  definition  is: 

<new  element  definition:*:  : = 

[DEFINE]  element-type-name  element-name  [comment]. 


^ [ INSERT]  <element  definition  sentence>|n 

<element  definition  sentence:*:  : = 
attribute  declaration:* 

| <relation  declaration;* 

| <path  declaration;* 

| structure  declaration:* 

5. 1.1.1  Declaring  a New  Element 

A new  element  is  declared  by  optionally  specifying  the  word  DEFINE, 
followed  by  an  element  type  name  for  the  element,  an  element  name,  and  an 
optional  comment  for  the  element. 

[DEFINE]  element-type-name  element-name  [comment]. 
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For  example,  the  following  are  all  valid  declarations  of  new  elements: 

DEFINE  ALPHA  PROCESS_VALID_RETURNS. 

DEFINE  DATA  OBJECTJD  (^UNIQUE  IDENTIFIER*). 

DEFINE  R_NET  ALLOCATE_RESOURCES. 

The  first  declaration  above  defines  an  element  named  PROCESS_VALID_RETURNS 
of  type  ALPHA.  The  second  declaration  defines  the  element  0BJECT_ID  of 
type  DATA.  The  third  declaration  defines  the  element  ALLOCATE_RESOURCES  of 
type  R_NET.  Elements  PROCESS_VALID_RETURNS  and  ALLOCATE_RESOURCES  are 
defined  with  no  associated  comments;  OBJECTJD  is  defined  with  a comment. 

The  syntax  for  declaring  a new  element  is  the  first  part  of  the 
complete  syntax  for  a new  element  definition. 

<new  element  definitions := 

[DEFINE]  element-type-name  element-name  [comment]. 

5. 1.1. 2 Declaring  an  Attribute  Value 

As  noted  above,  one  of  the  types  of  sentences  which  may  appear  within 
a new  element  definition  is  an  attribute  declaration,  optionally  preceded 
by  the  word  INSERT.  An  attribute  declaration  declares  an  attribute  value 
for  the  element  by  giving  the  name  of  the  attribute  followed  by  the 
desired  attribute  value  and  an  optional  comment. 

! value-name 

number  > [comment], 
text-string  ).| 

The  following  example  declares  several  attribute  values  for  the 
element  0BJECT_ID. 

DATA  OBJECTJD. 

TYPE  INTEGER. 

INITIALJALUE  0 (*PRESET  VALUE*). 

USE  BOTH. 

DESCRIPTION  "IDENTIFIER  FOR  AN  OBJECT". 

Any  number,  including  zero,  of  attribute  declarations  may  be  given 
for  an  element;  each  one  may  be  preceded  by  the  word  INSERT. 

Note  that  once  an  element  has  a value  for  a particular  attribute, 
it  is  always  necessary  to  remove  that  value  before  a new  value  for  the 
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same  attribute  can  be  declared.  The  process  of  modifying  element  defini- 
tions is  discussed  in  Section  5. 1.2. 3. 

Forms  of  Attribute  Values 

An  RSL  attribute  is  defined  in  terms  of  an  attribute  name,  a set  of 
one  or  more  element  types  to  which  the  attribute  may  apply,  and  a set  of 
allowable  values.  These  allowable  values  are  either  particular  value  names 
or  one  of  the  value  class  names  NAMED,  NUMERIC,  or  TEXT.  The  value  class 
names  have  the  following  interpretations: 

NAMED  - The  value  in  an  attribute  declaration  may  be  any  name 
not  used  in  a different  context. 

NUMERIC  - The  value  in  an  attribute  declaration  may  be  any  signed 
or  unsigned  integer  or  real  number  (see  Appendix  B). 

TEXT  - The  value  in  an  attribute  declaration  may  be  any  text 
string  (a  sequence  of  characters  enclosed  in  double 
quotes) . 

For  example,  attribute  LOCALITY  has  legal  values  GLOBAL  and  LOCAL, 
meaning  that  the  only  values  which  may  be  specified  for  LOCALITY  are  the 
names  GLOBAL  or  LOCAL.  The  attribute  INITIAL_VALUE  has  legal  values  NAMED 
and  NUMERIC  indicating  that  any  name  or  number  may  be  specified. 

The  syntax' for  declaring  an  attribute  value  is: 

[INSERT]  attribute  declaration> 

attribute  declarations  : = 

i value-name  J 

a ttribute- name  s number  / [comment]. 

(text-string)-j 


5. 1.1. 3 Declaring  a Relationship  Instance 

A relationship  is  established  between  the  subject  element  of  the  new 
element  definition  and  some  other  object  element  by  specifying  a relation 
declaration  optionally  preceded  by  the  word  INSERT.  The  relation  declara- 
tion gives  the  relationship  name,  perhaps  followed  by  the  appropriate 
relation  optional  word,  followed  by  the  types  and  names  of  one  or  more 
object  elements  and  optional  comments. 

[INSERT]  relation-name  [relation-optional -word] 


■j [element-type-name]  element-name 


[comment]  j>". 
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The  following  example  declares  several  relationships  between  DATA 
STATE  and  other  elements. 

DATA  STATE. 

INPUT  TO  ALPHA  UPDATE_STATE. 

INCLUDES  DATA  X 

DATA  Y (*N0RTH*) 

DATA  Z (*UP*). 

CONTAINED  IN  FILE  STATE_HISTORY  (*REC0RD  OF  STATE  CHANGES*). 

Each  comment  specified  in  a relationship  declaration  is  associated 
with  exactly  one  relationship  instance.  Thus  the  INCLUDES  declaration 
shown  above  establishes  three  instances  of  the  INCLUDES  relationship,  only 
two  of  which  have  comments;  i.e.,  relationship  instances  between  DATA  STATE 
and  each  of  the  DATA  elements  X,  Y,  and  Z are  established  but  only  the 
relationship  instances  to  Y and  Z have  associated  comments. 

On  the  assumption  that  the  element  named  in  a relationship  declara- 
tion has  already  been  defined,  the  element  type  name  need  not  be  specified. 
Thus, 

INPUT  TO  UPDATE_STATE. 
is  equivalent  to 

INPUT  TO  ALPHA  UPDATE_STATE. 

if  an  ALPHA  with  the  name  UPDATEJSTATE  has  been  previously  defined. 

As  in  other  declarations  about  an  element,  the  optional  word  INSERT 
may  be  specified  preceding  the  relationship  name  to  improve  the  readability 
of  the  input. 

The  appearance  of  an  element  type  name  and  an  element  name  in  a 
relationship  declaration  may  serve  as  an  implicit  declaration  of  the 
element  name.  The  reader  is  referred  to  Section  5.1.1 .6  for  a discussion 
of  this  type  of  declaration. 

Use  of  Relationship  and  Complementary  Relationship  Names 

A relationship  In  RSL  is  treated  like  a non-commutative  binary  re- 
lation; that  is,  a statement  of  an  association  between  a subject  element 
and  an  object  element  which  are  d ct.  For  each  relationship  there  Is 
a defined  set  of  element  types  which  may  serve  as  subjects  and  a defined 
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set  of  element  types  which  may  serve  as  objects.  For  each  relationship 
there  is  also  defined  a complementary  relationship  which  is  the  converse 
of  the  relationship  in  the  sense  that  the  subject  set  of  the  relationship 
is  the  object  set  of  the  complementary  relationship  and  the  object  set  of 
the  relationship  is  the  subject  set  of  the  complementary  relationship. 

This  duality  of  relationships-complementary  relationships  is  important 
in  the  statement  of  relationship  declarations  since  the  declaration  itself 
specifies  only  the  object  element;  the  subject  element  is  taken  to  be  the 
element  declared  in  the  preceding  element  declaration.  If  this  subject 
element  is  in  the  subject  set  for  a relationship,  then  the  relationship 
name  should  be  used.  Conversely,  if  this  subject  element  is  in  the  object 
set  for  a relationship,  then  the  complementary  name  should  be  used.  For 
exampl e : 

ALPHA  UPDATE_STATE. 

INPUTS  DATA  STATE. 

establishes  the  same  relationship  instance  as: 

DATA  STATE. 

INPUT  TO  ALPHA  UPDATE_STATE. 

The  syntax  for  declaring  a relationship  instance  is: 

[INSERT  <relation  declaration> 

<relation  declaration:*:  : = 

relation-name  [relation-optional -word] 

| [element-type-name]  element-name  [comment]^". 


5. 1.1. 4 Declaring  a Net  Structure 

A net  structure  may  be  declared  for  any  RSL  element  which  is  of  type 
R_NET  or  SUBNET  by  specifying  a structure  declaration,  optionally  preceded 
by  the  word  INSERT.  The  structure  declaration  itself  consists  of  the  word 
STRUCTURE  followed  by  two  or  more  node  constructs,  the  word  END  and  an 
optional  comment: 


[INSERT]  STRUCTURE  j<node>j"  END  [comment]. 
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There  are  two  classes  of  node  constructs,  primitive  and  complex.  The 
primitive  nodes  are  single  entry  and  single  exit  constructs.  The  complex 
nodes  are  multiple  entry  or  multiple  exit  constructs  and  express  information 
about  the  sequencing  of  the  nodes  they  contain. 

The  primitive  nodes  are  of  three  types:  the  element  node,  the  termi- 
nator node,  and  the  SELECT  node.  The  complex  nodes  are  of  four  types:  the 
FOR  EACH  node,  the  AND  node,  and  two  types  of  OR  nodes.  Each  of  these  node 
types  is  discussed  below. 

Formally,  a node  is  defined  as: 

<node> : := 

<element  node> 

<terminator> 

| <select  node> 

| <for-each  node> 

| <and  node> 

<or  node> 

| <consider-or  node> 

Rules  Regarding  Structures 

The  following  general  rules  are  enforced  for  structure  declarations. 

Additional  rules  relevant  to  particular  node  types  are  specified  in  the 
discussions  of  the  individual  node  types. 

1.  Each  path  through  a structure  must  be  terminated  by  a terminator 
node  or  by  an  OUTPUT_INTERFACE  element  node. 

2.  The  only  place  an  INPUT_INTERFACE  element  node  may  appear  is 
as  the  first  node  on  a structure  for  an  R_NET. 

3.  A RETURN  terminator  node  may  only  appear  on  a structure  for  a 
SUBNET  and  exactly  one  RETURN  must  appear  on  each  SUBNET 
structure. 

4.  A structure  may  only  be  declared  for  an  R_NET  or  a SUBNET. 

5.  No  more  than  one  structure  may  be  declared  for  any  R_NET  or 
SUBNET. 

Element  Node 

An  element  node  consists  of  an  element  type  name  followed  by  an 

* 

element  name  and  an  optional  comment.  If  the  element  has  been  previously 
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defined,  the  element  type  name  may  be  omitted.  If  the  element  has  not  been 
defined,  the  element  type  name  must  be  specified  and  the  element  is 
implicitly  defined  as  discussed  in  Section  5.1 .1.6.  In  either  case,  the 
comment  is  associated  with  the  structure  node,  not  with  the  element  itself. 
Element  nodes  may  only  be  constructed  from  elements  of  a type  which  is 
defined  with  STRUCTURE  APPLICABILITY  NET.  These  types  are  ALPHA,  EVENT, 
INPUT JNTERFACE,  0UTPUT_I NTERFAC E , SUBNET,  and  VALIDATION_POINT. 

A simple  two-node  structure  using  only  element  nodes  is  illustrated 

below. 

R_NET  ACCEPT_RETURN. 

STRUCTURE 

ALPHA  CHECKER  (*CHECK  VALIDITY  OF  DATA*) 

OUTPUTJ NTERFAC E P0ST_C0MMAND 

END. 

Formally,  an  element  node  is  defined  as: 

<element  node>::= 

[element-type-name]  element-name  [comment] 

Rules  for  Element  Nodes 

The  following  rules  regarding  element  nodes  are  enforced. 

1.  An  INPUT_INTERFACE  element  node  may  only  appear  as  the  first 
node  on  an  R_NET  structure. 

2.  An  INPUT_INTERFACE  element  node  may  not  appear  on  a SUBNET 
structure. 

3.  An  OUTPUT_INTERFACE  element  node  terminates  a path  of  a 
structure. 

Terminator  Node 

A terminator  node  or  0UTPUT_I NTERFAC E is  used  as  the  final  node  on 
a path  of  a structure.  Two  types  of  terminator  nodes  are  defined,  the 
RETURN  node  used  on  a structure  for  a SUBNET  to  indicate  the  point  at 
which  the  SUBNET  returns  to  its  calling  structure,  and  the  TERMINATE  node 
used  to  indicate  the  termination  of  a structure  branch.  The  syntax  of  a 
terminator  node  is  the  word  TERMINATE  or  RETURN,  optionally  followed  by 
a comment  for  the  node: 

TERMINATE  [comment] 

| RETURN  [comment] 


Two  simple  examples  of  structures  using  only  element  nodes  and 
terminator  nodes  are  given  below. 

SUBNET  SUB1 . 

STRUCTURE 

i 

ALPHA  CHECKER 
SUBNET  DOER 
RETURN 

END  (*CHECK  DATA  AND  PERFORM  ACTIONS*). 

R_NET  NET1 . 

STRUCTURE 

SUBNET  SUB1 

TERMINATE  (*END  OF  NET1*) 

END. 

Formally,  a terminator  node  is  defined  as: 

<terminator>:  :■ 

TERMINATE  [comment] 

| RETURN  [comment] 

Rules  for  Terminator  Nodes 

The  following  rules  are  enforced  for  terminator  nodes. 

1.  Exactly  one  RETURN  node  must  appear  on  each  SUBNET  structure. 

2.  A RETURN  node  may  not  appear  on  an  R_NET  structure. 

3.  A TERMINATE  or  RETURN  node  terminates  a path  on  a structure. 

SELECT  Node 

A SELECT  node  is  a primitive  node  which  selects  an  entity  based  upon 
the  value  of  a Boolean  expression.  The  syntax  for  a select  node  is: 

- rr_  ([ENTITYjCLASS]  entity-class-name 
itLtu  ^[ENTITY_type]  entity- type-name  ^ 

SUCH  THAT  <condition>  [comment] 

Thus,  the  basic  form  for  a select  node  is  one  of  the  following:  ■ j 

SELECT  ENTITY_CLASS  entity-class-name  j 

SUCH  THAT  (<Boolean  expression^ 
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or 


SELECT  ENTITY_TYPE  entity-type-name 
SUCH  THAT  (<Boolean  expression>) 

In  addition,  a comment  may  be  placed  after  the  (<Boolean  express1on>) . Also, 
if  the  entity  class  name  or  entity  type  name  is  already  defined,  the  pre- 
ceding element  type  name  may  be  omitted.  For  example,  the  following  are 
valid  SELECT  nodes. 

SELECT  ENTITY_CLASS  LARGE  SUCH  THAT  (X_ERR0R  >=  ERROR_LIMIT) 

SELECT  ENTITY JYPE  SMALL  SUCH  THAT  (X*Y  < LIMIT)  (*EXAMPLE*) 

Assuming  that  ENTITY_CLASS  LARGE  and  ENTITY_CLASS  SMALL  are  defined, 
the  following  two  SELECT  nodes  are  equivalent  to  those  above. 

SELECT  LARGE  SUCH  THAT  (X_ERR0R  >=  ERROR_LIMIT ) 

SELECT  SMALL  SUCH  THAT  (X*Y  < LIMIT)  (*EXAMPLE*) 

Examples  of  structures  including  SELECT  nodes  are: 

R_NET  RADAR_RETURN. 

STRUCTURE 

INPUTJNTERFACE  RETURN_BUFFER 
ALPHA  CHECKJALIDITY 
SELECT  ENTITY_CLASS  OBJECT  SUCH  THAT 
(RANGE  < PERIMETER_RANGE  + DELTA) 

SUBNET  UPDATE_THREAT_ESTIMATE 

END. 

SUBNET  U PDA T E_T HR EA T_E ST IM AT E . 

STRUCTURE 

ALPHA  RECORD JJPDATE  (*KEEP  A RUNNING  ACCOUNT*) 

SELECT  OBJECTJHREATENING  SUCH  THAT 

( (XD0T*XD0T  > XDOTLIM)  AND  (NOT  DECOY)) 

(* IGNORE  DECOYS*) 

END. 

Formally,  the  syntax  for  a SELECT  node  is: 
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<select  node>: := 

cr,  rpT  f [ENTITY_CLASS]  entity-cl ass-name)1 
([ENTITYJYPE]  entity-type-name 

SUCH  THAT  <condition>  [comment] 

condition  >:  :■ 

(< Boolean  expression^ 

Boolean  Expression 

A Boolean  expression  is  in  a form  designed  to  mirror  acceptable  PDL  2 
Boolean  expressions  with  the  exception  that  function  references  and  set 
inclusion  (IN)  are  not  allowed.  The  Boolean  expression  is  a rule  of  compu- 
tation that,  upon  execution,  produces  a value  of  TRUE  or  FALSE.  Some 
examples  of  typical  Boolean  expressions  are: 

X + 30  = Y 

(YDOT  <=  1500)  = (XDOT  >=  1800) 

A OR  ((NOT  B)  AND  (NOT  (C  OR  D))) 

The  complete  formal  definition  of  a Boolean  expression  is  presented 
in  Appendix  D.  The  typical  user  is  expected  to  have  little  or  no  reason 
to  ever  be  concerned  with  this  formal  definition  but  should  be  aware  of  the 
following  considerations: 

1.  If  more  than  one  operator  occurs  in  a Boolean  expression, 
the  sequence  of  execution  may  be  defined  explicitly  with 
parentheses  or  implicitly  by  the  rule  of  operator  precedence. 

Since  the  operator  precedence  may  differ  for  different  imple- 
mentations of  PDL  2 or  PASCAL,  the  user  is  advised  to  fully 
parenthesize  all  Boolean  expressions. 

2.  The  appearance  of  an  undefined  name  in  a Boolean  expression 
will  result  in  an  implicit  definition  of  that  name  as  an 
element  of  type  DATA  as  discussed  in  Section  5. 1.1 .6. 

3.  If  a data  name  has  a value  BOOLEAN  for  the  attribute  TYPE  it 
will  be  treated  as  a <Boolean  primary>  (equivalent  to  a TRUE 
or  FALSE).  Otherwise,  it  will  be  treated  as  an  <arithmetic 
factor>  (equivalent  to  a number).  The  lack  of  a value 
BOOLEAN  for  the  attribute  TYPE  in  a context  in  which  a 
<Boolean  primary>  is  required  will  result  in  the  detection 
of  a syntax  error  by  the  RSL  translator. 

FOR  EACH  Node 

A FOR  EACH  node  consists  of  two  physical  nodes  in  a structure.  The 
first  node,  termed  the  FOR  EACH  subject,  is  similar  to  an  element  node 
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except  that  the  element  type  name  must  be  FILE,  ENTITY_TYPE,  or  ENTITY_CLASS 
and  the  optional  comment  appears  after  the  word  DO  in  the  syntax  of  the 


FOR  EACH  node.  The  second  node,  termed  the  FOR  EACH  body,  is  also  similar 
to  an  element  node,  except  that  the  element  type  name  must  be  ALPHA  or 
SUBNET.  An  optional  comment  follows  the  element  name,  and  the  entire  FOR 
EACH  body  is  bracketed  by  the  words  DO  and  END. 

([FILE]  file-name  [RECORD]  i1 

FOR  EACH < [ENTITYJTYPE]  entity-type-name  / [SUCH  THAT  <condition>] 
( [ENTITY_CLASS]  entity-class-name  ) ^ 

DO  [comment]  {^^t^Lef!  ™ 

, 

Examples  of  simple  FOR  EACH  nodes  are: 

FOR  EACH  FILE  OBJECTS_IN_TRACK 
DO  ALPHA  CHECK_RANGE  END 

FOR  EACH  ENTITYJTYPE  THREAT 

DO  (*L00K  AT  ALL  THREATS*)  SUBNET  CHECK_RANGE  END 

Two  additional  options  are  available  on  a FOR  EACH  node.  First,  the 
execution  of  the  FOR  EACH  body  may  be  made  conditional  based  upon  the  value 
of  some  Boolean  expression.  This  is  accomplished  by  specifying  the  words 
SUCH  THAT  and  a Boolean  expression  enclosed  in  parentheses  immediately 
preceding  the  word  DO.  The  second  option  is  that  if  the  FOR  EACH  subject 
names  a FILE,  the  optional  word  RECORD  may  follow  the  file  name. 

Examples  include: 

FOR  EACH  FILE  OBJECTS_IN_TRACK  RECORD 
DO  ALPHA  CHECK  RANGE  END 


FOR  EACH  ENTITY_CLASS  RANGE_MARK 

SUCH  THAT  (AMPLITUDE  >=  NOISE  + AMPJ5ELTA) 

DO  SUBNET  BULK_FILTER  (*REM0VE  SLOW  OBJECTS*)  END 

As  with  other  nodes  on  a structure,  the  element  type  name  may  be 
omitted  if  the  element  is  already  defined.  If  the  element  has  not  been 
defined,  the  element  type  name  must  be  supplied  and  the  element  is 
implicitly  defined. 

Formally,  a FOR  EACH  node  is  defined  as: 
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<for-each  node>::* 

([FILE]  file-name  [RECORD] 

FOR  EACH  < [ENTITY J-YPE]  entity-type-name 
I [ENTITY_CLASS]  entity-class-name 

DO  [comment]  1—3  “ 

AND  node 

The  AND  node  is  a complex  node  with  one  entry  arc  and  several  exit  arcs 
leading  to  parallel  branches.  There  are  two  classes  of  AND  nodes,  rejoining 
and  non-rejoining.  In  a rejoining  AND  node  all  of  the  branches  rejoin  at  a 
virtual  AND  node  with  multiple  entry  arcs  and  a single  exit  arc.  In  a non- 
rejoining AND  node,  the  branches  do  not  rejoin;  each  of  them  ends  with  a 
TERMINATE,  RETURN,  or  OUTPUT  INTERFACE  node  and  there  Is  no  virtual  AND  node. 


> [SUCH  THAT  <condition>] 
-1 


An  AND  node  is  written  as  the  word  DO,  with  an  optional  comment  for  the 
AND  node,  followed  by  two  or  more  branches  separated  by  the  word  AND;  the 
entire  construct  is  terminated  with  the  word  END.  A branch  is  simply  defined 
to  be  a sequence  of  one  or  more  nodes.  The  syntax  for  an  AND  node  is: 


DO  [comment]  <branch> 


{ 


AND  <branch> 


END 


Some  simple  rejoining  AND  nodes  include  the  following: 

DO  (*TW0  BRANCH  AND  NODE*) 

ALPHA  ONE 
SUBNET  TWO 
AND 

FOR  EACH  FILE  THREE 
DO  ALPHA  FOUR  END 
END 

DO  (*THREE  BRANCH  AND  NODE*) 

SELECT  ENTITY_CLASS  EC_1  SUCH  THAT  (X  <=  Y + 5.0) 
ALPHA  CHECKER 
ALPHA  DOER 
AND 

SELECT  ENTITY_CLASS  EC_1  SUCH  THAT  (LARGEJETA) 
SUBNET  CHECK  R DOT 
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AND 


ALPHA  RECORD_HISTORY 
END 

An  example  of  a non-rejoining  AND  node  is  the  following: 

DO  (*B0TH  BRANCHES  TERMINATE*) 

ALPHA  0UTPUT_ HISTORY 
TERMINATE 
AND 

SUBNET  FORM_RADAR_REQUEST 
OUTPUTJNTERFACE  RADAR_ORDERS 
END 

Since  a branch  is  simply  a sequence  of  nodes,  AND  nodes  may  be 
embedded  within  other  AND  nodes  to  any  level  desired.  The  following 
example  embeds  an  AND  node  within  the  scope  of  another  AND  node. 

DO  (* ILLUSTRATE  EMBEDDING*) 

ALPHA  CHECKER 
DO  (*EMBEDDED  AND  NODE*) 

ALPHA  DOER 
AND 

SUBNET  CHECK_RANGE 
AND 

ALPHA  UPDATE_HIST0RY 
END 
AND 

SUBNET  SELECTJ.ARGEST 
END 


Formally,  the  syntax  for  an  AND  node  is: 

<and  node>::= 

DO  [comment]  <branch>|AND  <branch>j^  END 
<branch>: := 

|<node>|^ 


r , ...  _ ■ , i 


Rules  Regarding  AND  Nodes 

The  following  rules  are  enforced  for  AND  nodes. 

1.  Each  branch  of  an  AND  node  must  end  in  a TERMINATE,  RETURN,  or 
OUTPUT_INTERFACE  or  they  all  must  rejoin.  A mixture  of 
terminating  and  non-terminating  branches  Is  not  allowed. 

2.  There  must  be  at  least  two  branches,  i.e.,  the  word  AND  must 
appear  at  least  once. 

3.  The  words  DO  and  END  completely  bracket  the  AND  node. 

4.  No  node  in  a structure  may  follow  a non-rejoining  AND  node 
since  all  branches  in  a non-rejoining  AND  node  terminate. 

OR  Node 

Like  the  AND  node,  the  OR  node  is  a complex  node  with  a single  entry 
arc  and  multiple  exit  arcs.  The  meaning,  however,  is  that  only  one  of  the 
exit  branches  is  to  be  followed.  The  branch  to  be  followed  is  determined 
by  the  value  of  Boolean  expressions  given  for  each  branch.  The  order  in 
which  the  Boolean  expressions  are  to  be  evaluated  may  be  specified  by 
assigning  ranking  ordinals  to  the  branches.  In  the  absence  of  ordinals, 
the  lexical  ordering  of  the  input  text  is  used  to  determine  the  evaluation 
order.  To  cover  the  case  where  all  Boolean  expressions  may  evaluate  to 
false,  an  otherwise  clause  is  used. 

Again,  like  the  AND  node,  the  OR  node  may  be  rejoining  or  non-rejoining. 
If  the  OR  node  is  rejoining,  all  the  branches  rejoin  at  a virtual  OR  node. 

If  the  OR  node  is  non-rejoining,  each  branch  ends  with  a TERMINATE  or  RETURN 
node  or  OUTPUT_INTERFACE  element  node  and  there  Is  no  virtual  OR  node. 

An  OR  node  is  written  as  the  word  IF,  with  an  optional  comment  for  the 
OR  node,  followed  by  one  or  more  conditional  branches  separated  by  the  word 
OR,  in  turn  followed  by  the  word  OTHERWISE,  an  optional  branch,  and  the  word 
END.  A conditional  branch  consists  of  an  optional  unsigned  integer  repre- 
senting an  ordinal  for  the  branch,  followed  by  a Boolean  expression  enclosed 
in  parentheses  and  a sequence  of  one  or  more  nodes.  The  syntax  for  an  OR 
node  is: 

( 1 n 

IF  [comment]  [unsigned-integer]  (<Boolean  expression^^nodo^ 

| OR  [unsigned -integer]  (<Boolean  expression^  <|<node>^ 

OTHERWISE  j<node>j"  END 


A 


f 

>0 
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An  example  of  a rejoining  OR  node  not  using  ordinals  is  the  following: 


IF  (*TW0  BRANCHES*) 

(X  > Y)  ALPHA  X_LARGER 
OR 

(X  < Y)  ALPHA  Y_LARGER 
OTHERWISE 

ALPHA  X_Y_EQUAL 
END 

An  example  of  a non-rejoining  OR  node  using  ordinals  is  the  following: 

IF  (*TW0  BRANCHES,  EMPTY  OTHERWISE*) 

2 (RANGE  <=  FAR_LIMIT) 

ALPHA  CONSIDER_OBJECT 
SUBNET  UPDATE_STATE 
TERMINATE 
OR 

1 (RANGE  >=  NEARJ.IMIT) 

SUBNET  DR0P_0BJ ECT 
TERMINATE 
OTHERWISE 
TERMINATE 
END 

Like  AND  nodes,  OR  nodes  may  be  nested  to  any  level.  For  example,  the 
following  illustrates  an  OR  node  with  a nested  OR  node. 

IF 

((X  + Y)  = 2 + 30) 

IF  (*NESTED  OR  node*) 

(X  > Z + 5) 

ALPHA  ONE 
ALPHA  TWO 
OR 

(Z  - 10  < 25) 

ALPHA  THREE 
OTHERWISE 
END 


5-19 


OR  (X  > Y) 

ALPHA  FOUR 
OTHERWISE 
END 

Formally  the  syntax  for  an  OR  node  is: 


<or  node>: := 


IF  [comment]  conditional  branch>  joR  conditional  branch>l 

{ ’0 

OTHERWISE  [<branch>]  END 


conditional  branch>::  = 

[unsigned  integer]  ccondition>  <branch> 

cbra nch>::= 


•j<node>j^ 


Rules  Regarding  OR  Nodes 

The  following  rules  regarding  OR  nodes  are  enforced. 


1.  Each  branch  of  an  OR  node  must  end  in  a TERMINATE,  RETURN,  or 
OUTPUTJNTERFACE  or  they  all  must  rejoin.  A mixture  of 
terminating  and  non-terminating  branches  Is  not  allowed. 

2.  There  must  be  at  least  one  branch  plus  an  otherwise  clause, 
i.e.,  the  word  OR  is  not  required  to  appear  but  the  word 
OTHERWISE  is  required. 

3.  Ordinals  must  be  unsigned  integers  between  1 and  9999 
inclusive. 

4.  No  two  branches  can  have  the  same  ordinal. 

5.  Either  all  branches  (except  the  OTHERWISE)  must  have  ordinals 
or  none  may  have  ordinals.  A mixture  of  ordinal  and  non- 
ordinal branches  is  not  allowed. 

6.  The  words  IF  and  END  completely  bracket  the  OR  node. 

7.  No  node  may  follow  a non-rejoining  OR  node  in  a structure 
since  all  branches  in  a non-rejoining  OR  node  terminate. 

CONSIDER  OR  Node 


The  CONSIDER  OR  node,  like  the  OR  node,  is  a complex  node  with  a 
single  entry  arc  and  multiple  exit  arcs.  The  intended  meaning  is  that  only 
one  of  the  exit  branches  is  to  be  followed;  the  correct  branch  being 
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determined  by  the  element  name  being  considered,  termed  the  consider- 
subject,  and  the  names  specified  in  the  conditional  expressions  for  each 
branch. 


v 

I\ 


Again,  like  the  OR  node,  the  CONSIDER  OR  node  may  be  rejoining  or 
non-rejoining.  If  the  CONSIDER  OR  node  is  rejoining,  all  the  branches 
rejoin  at  a virtual  OR  node.  If  the  CONSIDER  OR  node  is  non-rejoining, 
each  branch  ends  with  a TERMINATE,  RETURN,  or  0UTPUT_I NT ER FAC E node  and 
there  is  no  virtual  OR  node. 

There  are  two  types  of  CONSIDER  OR  nodes,  the  consider -data  and  the 
consider -entity-class;  distinguished  by  the  element  type  of  the  element 
used  as  the  consider-subject.  For  either  type,  the  CONSIDER  OR  node  is 
written  in  the  same  manner:  the  word  CONSIDER,  an  optional  element  type 
name  DATA  or  ENTITY_CLASS  and  a data  or  entity  class  name,  followed  by  the 
word  IF  with  an  optional  comment,  followed  in  turn  by  two  or  more  consider 
branches  separated  by  the  word  OR,  followed  by  the  word  END.  Each  consider 
branch  consists  of  a consider  list  enclosed  in  parentheses  followed  by 
zero  or  more  nodes  comprising  the  branch.  The  form  of  the  consider  list 
is  a sequence  of  one  or  more  names  separated  by  the  word  OR.  If  the 
consider-subject  is  a data  name,  these  names  are  assumed  to  be  values  in 
its  RANGE.  If  the  consider-subject  is  an  entity  class  name,  these  names 
are  assumed  to  be  entity  type  names  and  implicit  declarations  will  result 
if  they  have  not  been  previously  defined. 


The  syntax  for  a consider -data  node  is: 


CONSIDER  [DATA]  enumerated-data-name 
IF  [comment]  ( enumeration-value-name 


{ 


OR  enumeration-value-name 


fn°de>}o 

joR  ^enumeration-value-name  J OR  enumerat ion-value-name j j-node- j ^ j 


END 


< b 
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The  syntax  for  a consider-entity-class  node  is: 

CONSIDER  [ENTITY_CLASS]  entity-cl ass-name 

IF  [comment]  ^entity- type-name  joR  enti ty- type-name ^ j<node>|^ 

n 

joR  ^entity-type-name  joR  entity-type-namej^  j<node>^| 

END 

Examples  of  a CONSIDER  OR  node  are  the  following: 

CONSIDER  DATA  OBJECT_CLASSIFICATION 
IF  (*BRANCH  ON  CLASS*) 

(UNKNOWN  OR  RV) 

SUBNET  CHECKJETA 
OR 

(DECOY) 

SUBNET  CHECKJETA 
ALPHA  UPDATEJEIGHT 
OR 

(JUNK) 

END 

CONSIDER  ENTITYJLASS  OBJECT 
IF  (*BRANCH  ON  AGE  OF  OBJECT*) 

(ANCIENT  OR  VERYJLD  OR  OLD) 

ALPHA  UPDATE_AGE 
TERMINATE 
OR 

(YOUNG) 

ALPHA  CHEC ^CHARACTERISTICS 
SUBNET  UPDATE JTATE 
OUTPUTJNTERFACE  TRACKJEQUEST 
OR 

(INFANT) 

SUBNET  UPDATE  JTATE 
OUTPUTJNTERFACE  TRACKJEQUEST 
END 
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Differences  Between  OR  Nodes  and  CONSIDER  OR  Nodes 

Although  there  are  many  similarities  between  OR  nodes  and  CONSIDER  OR 
nodes,  the  following  differences  should  be  kept  in  mind. 

1.  An  OTHERWISE  branch  is  required  on  an  OR  node  and  not  allowed 
on  a CONSIDER  OR  node. 

2.  The  only  branch  which  may  be  empty  on  an  OR  node  is  the 
OTHERWISE  branch.  Any  one  of  the  branches  on  a CONSIDER  OR 
node  may  be  empty  (but  only  one). 

3.  The  branch  conditions  for  an  OR  node  must  be  Boolean  expres- 
sions. For  a CONSIDER  OR  node,  the  branch  condition  must  be 
one  or  more  value  names  or  entity  type  names  separated  by 
the  word  OR. 

4.  Ordinals  are  optional  on  OR  node  branches  and  not  allowed  on 
CONSIDER  OR  node  branches. 

Formally,  the  syntax  for  a CONSIDER  OR  node  is: 

<consider-or  node>::= 

<consider-data> 

| <consider-entity-class> 

<consider-data>: := 

CONSIDER  [DATA]  enumerated -data -name 

IF  [comment]  <consider-data  branch> 

( 1 n 

<0R  <consider-data  branch>S 
1 Jl 

END 

<consider-data-branch>: := 

^enumeration-value-name  |or  enumeration-value  namej-^  [<branch>] 


<consider-entity-class>: := 

CONSIDER  [ENTITY_CLASS]  entity-class-name 
IF  [comment]  consider-entity-branch 

-joR  <consider-entity-branch>j^ 


<consider-enti ty-branch> : : = 

(entity-type-name  joR  entity-type-namej^  ) [<branch>] 
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The  following  rules  are  enforced  for  CONSIDER  OR  nodes. 


1.  The  consider-subject  must  be  of  type  DATA  or  ENTITY_CLASS. 

2.  If  the  consider-subject  is  of  type  DATA,  it  must  have  the 
value  ENUMERATION  for  attribute  TYPE  or  it  must  have  no 
value  for  attribute  TYPE. 

3.  For  a consider -data , the  names  in  the  consider-list  must  not 
be  known  names.  (Note:  The  RSL  translator  has  no  knowledge 
of  names  which  were  entered  inside  of  text  strings,  such  as 
the  value  for  attribute  RANGE.)  They  are  assumed  to  be  value 
names  contained  within  the  RANGE  for  the  data. 

4.  For  a consider-entity-class,  if  the  names  in  the  consider-list 
are  known  names,  they  must  be  entity  type  names. 

5.  A CONSIDER  OR  node  may  have  at  most  one  empty  branch  and  must 
have  at  least  one  non-empty  branch. 

6.  Each  branch  of  a CONSIDER  OR  node  must  end  in  a TERMINATE  or  RETURN 
node  or  OUTPUT_INTERFACE  element  node  or  they  all  must  rejoin. 

A mixture  of  terminating  and  non-terminating  branches  is  net 
a 1 1 owed . 

5.1 .1.5  Declaring  A Path 

A path  may  be  declared  for  any  RSL  element  which  is  of  type  VALIDATION_ 
PATH,  by  specifying  a path  declaration  optionally  preceded  by  the  word  INSERT. 
The  path  declaration  itself  consists  of  the  word  PATH  followed  by  one  or  more 
element  nodes,  the  word  END,  and  an  optional  comment.  Formally,  this  is 
shown  as: 

[INSERT]  PATH  |<element  node>|  ^ END  [comment]. 

Each  element  node  consists  of  an  element  type  name  followed  by  an 
element  name  and  an  optional  comment.  If  the  element  has  been  previously 
defined,  the  element  type  name  may  be  omitted.  If  the  element  has  not  been 
defined,  the  element  type  name  must  be  specified  and  the  element  is 
implicitly  defined  (see  Section  5.1.1 .6).  In  either  case,  the  conment  Is 
associated  with  the  path  node  and  not  with  the  element  itself. 

Element  nodes  on  a path  may  be  constructed  only  from  elements  of  a 
type  defined  with  STRUCTURE  APPLICABILITY  PATH.  The  types  so  defined  are 
EVENT  and  VALIDATION  POINT. 
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Examples  of  path  declarations  include  the  following: 

VALIDATION_PATH  VP_1  . 

PATH 

EVENT  TRIGG ER_R_NET_ONE 
VAL IDAT I0N_P0 INT  RECORD_DATA 
EVENT  TRIGG ER_R_NET_TWO 

END. 


VAL IDAT I0N_PATH  CHECK_TIMING. 

PATH 

VAL I DAT 1 0N_P0 INT  R EC ORD_RADAR_R ETU R N S 
EVENT  SCHEDULE_PULSES  (*ENABLE  SCHEDULER*) 
VAL IDAT I0N_P0 1 NT  RECORD_RADAR JDRDERS 
END  (*CHECK  TIMING*). 

The  syntax  for  declaring  a path  is: 


[INSERT]  <path  declaration> 
<path  declarations  : = 


PATH  |<element  node>|  END  [comment]. 

<element  node>::= 

[element-type-name]  element-name  [comment] 

5. 1.1. 6 Implicit  Element  Declarations 

An  element  may  be  declared  either  explicitly,  by  being  the  subject 
element  of  an  element  definition,  or  implicitly,  by  being  referenced  as 
part  of  a relationship,  structure,  or  path  declaration.  For  example,  the 
element  definition: 

DEFINE  R_NET  R1 . 

ENABLED  BY  EVENT  El. 

STRUCTURE 
ALPHA  A1 
TERMINATE 

END. 


hi  A ■ 


implies  the  element  declarations: 

DEFINE  EVENT  El. 

DEFINE  ALPHA  A1 . 
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With  two  exceptions,  an  element  type  name  must  be  explicitly  stated 
in  order  for  an  implied  element  declaration  to  be  allowed.  For  example, 
if  El  and  A1  had  not  been  previously  declared,  then  the  above  example  would 
be  legal,  but  the  following  would  not  be  legal: 

DEFINE  R_NET  R1 . 

ENABLED  BY  El. 

STRUCTURE 

A1 

TERMINATE 

END. 

Note  that  an  element  type  name  applies  only  to  the  element  name  that 
immediately  follows  it.  For  example,  in  the  following,  DATA  applies  only 
to  DAT1  and  not  to  DAT2  or  DAT3: 

ALPHA  AL1 . 

INPUTS  DATA  DAT1 , DAT 2,  DAT3. 

The  two  exceptions  to  the  rule  that  an  undefined  element  name  must 
always  be  preceded  by  an  element  type  name  occur  in  Boolean  expressions 
and  consider-1 ists.  In  a Boolean  expression,  undefined  names  encountered 
are  implicitly  defined  to  be  of  type  DATA;  the  element  type  name  DATA  must 
not  appear.  In  a consider-1 ist  for  a consider-entity  type  of  CONSIDER  OR 
node,  undefined  names  encountered  are  implicitly  defined  to  be  of  type 
ENTITY_TYPE;  the  element  type  name  ENTITY_TYPE  must  not  appear. 

5.1.2  Modifying  an  Element  Definition 

Once  an  element  has  been  defined,  it  is  often  necessary  to  refine  or 
modify  that  definition  in  some  way.  These  modifications  include  the 
insertion  of  new  declarations  and  the  removal  of  existing  declarations. 

Each  of  these  types  of  modifications  as  they  relate  to  the  RSL  concepts  of 
elements,  attributes,  relationships,  structures,  and  paths  are  discussed 
below.  In  several  cases  the  material  would  basically  be  a restatement  of 
material  presented  in  previous  sections  of  this  document;  the  user  will  be 
referred  to  those  sections. 

The  format  used  to  modify  the  definition  of  an  element  closely 
follows  that  used  to  define  a new  element.  First  a declaration  must  be 
given  of  the  subject  element  which  is  to  be  modified.  This  declaration 
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is  followed  by  the  declarations  of  the  desired  changes  for  the  subject 
element.  The  syntax  for  an  element  modification  is: 

[MODIFY]  element-type-name  element-name  [comment]. 

[INSERT]  <element  definition  sentence>\  n 

attribute  declaration  removal>  I 

^relationship  declaration  removal>  > 

<structure  declaration  removal > 1 

<path  declaration  removal > / ^ 

As  shown  in  the  syntax,  the  word  MODIFY  is  optional  in  an  element 
modification.  If  the  element  to  be  modified  exists  in  the  ASSM  then  MODIFY 
will  be  assumed  and  need  not  be  stated.  If,  however,  the  element  is  not 
defined  in  the  ASSM,  the  RSL  function  assumes  that  this  is  a new  element 
definition.  Because  of  this  assumption,  the  user  is  safest  if  he  always 
uses  the  word  MODIFY  when  modifying  an  element. 

The  word  INSERT  is  also  optional  before  an  element  definition  sentence. 
Here,  the  use  or  omission  of  the  word  INSERT  has  no  effect  on  the  interpre- 
tation of  the  input. 

5. 1.2.1  Declaring  the  Element  to  be  Modified 


The  declaration  of  the  subject  element  to  be  modified  is  given  by 
optionally  specifying  the  word  MODIFY,  followed  by  the  element  type  name, 
element  name,  and  optional  comment  for  the  element. 

[MODIFY]  element-type-name  element-name  [comment]. 

The  main  purpose  of  this  declaration  is  to  specify  which  element  is  to  be 
modified  in  the  following  declarations.  It  also  may  serve  to  modify  the 
element  definition  itself  since, if  a comment  is  specified,  it  will  replace 
any  existing  comment  associated  with  the  element.  If  no  comment  is  speci- 
fied, any  existing  comment  for  the  element  will  be  retained.  For  example, 
the  first  example  below  retains  any  existing  comment  for  AL1  while  the 
second  associates  the  comment  "(*NEW  COMMENT*)"  with  the  element  AL2. 

MODIFY  ALPHA  AL1 . 

MODIFY  ALPHA  AL2  (*NEW  COMMENT*). 
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The  syntax  used  to  declare  the  element  to  be  modified  is: 


<element  modifications-:  : = 

[MODIFY]  element-type-name  element-name  [comment]. 

5. 1.2. 2 Declaring  an  Attribute  Value 

There  is  no  difference  between  declaring  attribute  values  for  an 
existing  element  and  declaring  attribute  values  for  a new  element.  The 
reader  is  referred  to  Section  5. 1.1. 2 above  for  a discussion  of  declaring 
attribute  values. 

5 . 1 . 2 . 3 Removing  an  Attribute  Value 

An  existing  attribute  value  for  an  element  is  removed  by  specifying 
the  word  REMOVE  followed  by  the  name  of  the  attribute.  Notice  that  the 
attribute  value  itself  is  not  specified,  nor  is  a comment. 

REMOVE  attribute-name. 

The  following  example  first  defines  an  element  DAT1  with  several 
attributes,  then  the  element  definition  is  modified  to  remove  attributes 
USE  and  INITIAL_VALUE,  other  attributes  for  DAT1  remaining  intact.  A new 
value  for  attribute  INITIALJ/ALUE  is  then  declared. 

DEFINE  DATA  DAT1  . 

TYPE  INTEGER. 

USE  GAMMA. 

INITIALJ/ALUE  0 (*N0MINAL  VALUE*). 

MAXIMUMJ/ALUE  100. 

MODIFY  DATA  DAT1 . 

REMOVE  USE. 

REMOVE  INITIALJ/ALUE. 

INSERT  INITIALJ/ALUE  -1. 

1 

Rules  Regarding  Removal  of  Attribute  Values 

The  following  rules  are  enforced  on  removal  of  attribute  values. 

. 

2.  The  attribute  value  must  not  be  specified. 

3.  The  removal  of  an  attribute  value  also  removes  any  comment 
associated  with  the  attribute  value  for  the  element. 


i 
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4.  If  a comment  is  specified  after  the  attribute  name,  an  infor- 
mative error  diagnostic  will  be  generated  and  the  comment 
ignored.  The  removal  will,  however,  still  be  accomplished. 

Formally,  the  syntax  for  removing  an  attribute  value  is: 

attribute  declaration  removal>::  = 

REMOVE  attribute-name. 


5. 1.2. 4 Declaring  a Relationship  Instance 

There  is  no  difference  between  declaring  a relationship  instance  for 
an  existing  element  and  declaring  a relationship  instance  for  a new  element. 
The  reader  is  referred  to  Section  5. 1.1. 3 above  for  a discussion  of 
declaring  relationship  instances. 


5. 1.2. 5 Removing  a Relationship  Instance 

A relationship  between  the  subject  element  and  one  or  more  object 
elements  is  removed  by  specifying  the  word  REMOVE,  the  relationship  name 
optionally  followed  by  the  appropriate  relation  optional  word  for  the 
relationship,  followed  by  the  names  of  the  object  elements.  Each  of  these 
object  element  names  may  be  preceded  by  its  element  type  name. 


REMOVE  relation-name  [relation-optional -word] 
[element-type -name]  el ement-namel  . 


Jl 


Assume  that  DAT2  is  defined  as  follows: 


DEFINE  DATA  DAT 2 (*DUMMY  EXAMPLE*). 

INPUT  TO  ALPHA  AL2  (*DAT2  - AL2*) , 

ALPHA  AL21 , 

ALPHA  AL22. 

INCLUDES  DATA  DAT21 , 

DATA  DAT22  (*DAT2  - DAT22*) . 

The  following  will  remove  the  relationship  INPUT  between  DAT2  and  both  AL21 
and  AL2.  It  will  also  remove  the  relationship  INCLUDES  between  DAT2  and 
DAT22. 


MODIFY  DATA  DAT2. 

REMOVE  INPUT  AL2,  ALPHA  AL21 . 
REMOVE  INCLUDES  DATA  DAT22. 


5-29 


Since  a relationship  instance  relates  a subject  to  an  object,  it  is  always 
possible  to  remove  the  relationship  instance  from  either  viewpoint.  The 
following  modifications  accomplish  exactly  the  same  effect  as  those  above. 


MODIFY  ALPHA  AL2. 

REMOVE  INPUTS  DATA  DAT 2. 

MODIFY  ALPHA  AL21 . 

REMOVE  INPUTS  DAT 2. 

MODIFY  DATA  DAT22. 

REMOVES  INCLUDED  IN  DAT 2. 

The  net  effect  of  either  set  of  modifications  is  to  leave  DAT2  as  if  it 
were  defined: 

DATA  DAT2  (*DUMMY  EXAMPLE*). 

INPUT  TO  ALPHA  AL22. 

INCLUDES  DATA  DAT21 . 

The  formal  syntax  for  the  removal  of  relationship  instances  is: 

"relationship  declaration  removal>::= 

REMOVE  relation-name  [relation-optional -word] 


| [element-type-name]  element-namej^ . 


Rules  Regarding  Removal  of  Relationship  Instances 

The  foil  owing  rules  are  enforced  on  removal  of  relationship  instances. 

1.  The  word  REMOVE  must  be  specified. 

2.  The  removal  of  a relationship  instance  also  removes  any 
comment  associated  with  that  instance. 

3.  If  a comment  is  specified  after  an  element  name,  an  informa- 
tive error  diagnostic  will  be  generated  and  the  comment 
ignored.  The  removal,  however,  will  still  be  accomplished. 

5 . 1 . 2 . 6 Declaring  a Net  Structure 

There  is  no  difference  between  declaring  a structure  for  an  existing 
element  and  declaring  a structure  for  a new  element.  The  reader  is  referred 
to  Section  5. 1.1. 4 above  for  a discussion  of  declaring  a structure  for  an 
element. 
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5 . 1 . 2 . 7 Removing  a Net  Structure 

A structure  for  an  element  is  removed  by  specifying  the  word  REMOVE 
followed  by  the  word  STRUCTURE.  For  example,  if  SUB1  is  defined  as 
follows: 

DEFINE  SUBNET  SUB1 . 

STRUCTURE 

FOR  EACH  ENTITY_CLASS  EC1 
DO  SUBNET  SUB2  END 
DO  ALPHA  AL1 
AND  ALPHA  AL2 
AND  ALPHA  AL3 
END 

RETURN 

END  (*ARBITRARY  STRUCTURE*). 

the  text: 

MODIFY  SUBNET  SUBl . 

REMOVE  STRUCTURE. 

will  remove  the  structure  associated  with  SUBl  and  its  comment. 

Formally,  the  syntax  for  removal  of  a structure  is: 

structure  declaration  removal>::  = 

REMOVE  STRUCTURE. 

Rules  Regarding  Removal  or  Structures 

The  following  rules  are  enforced  for  removal  of  structures. 

1.  The  word  REMOVE  must  be  specified. 

2.  The  removal  of  a structure  also  removes  any  comment  associated 
with  the  structure. 

3.  If  a comment  is  specified  after  the  word  STRUCTURE.an  informative 
error  diagnostic  will  be  generated  and  the  conment  ignored.  The 
removal  of  the  structure  will  still  be  accomplished. 

5. 1.2. 8 Declaring  a Path 

Declaring  a path  for  an  existing  element  is  no  different  from  declaring 
a path  for  a new  element.  The  reader  is  referred  to  Section  5. 1.1. 5 for  a 
discussion  of  declaring  a path  for  an  element. 
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5. 1.2. 9 Removing  a Path 

A path  for  an  element  is  removed  by  specifying  the  word  REMOVE 
followed  by  the  word  PATH.  For  example,  if  VAL_1  is  defined  as  follows: 

DEFINE  VALIDATION_PATH  VALJ  . 

PATH 

VALIDATION_POINT  VP_0NE 
EVENT  EVT_0NE 
VAL IDAT I0N_P0 1 NT  VP_TW0 
END  (*DUMMY  PATH*). 

the  text: 

MODIFY  VAL IDAT I0N_PATH  VALJ  . 

REMOVE  PATH. 

will  remove  the  path  associated  with  VALJ  and  its  comment. 

Formally,  the  syntax  for  removal  of  a path  is: 

<path  declaration  removal>::= 

REMOVE  PATH. 


I 


Rules  Regarding  Removal  of  Paths 

The  following  rules  are  enforced  by  the  RSL  translator  for  removal 
of  paths. 

The  word  REMOVE  must  be  specified. 


1. 

2. 


The  removal  of  a path  also  removes  any  comment  associated 
with  the  path. 


3. 


If  a comment  is  specified  after  the  word  PATH,  an  informative 
error  diagnostic  will  be  generated  and  the  comment  ignored. 
The  removal  of  the  path  is  still  accomplished. 


5.1.3  Deleting  an  Element 

An  element  may  be  deleted  only  if  it  has  no  relationships  to  any 
other  elements,  has  no  associated  structure  or  path,  and  is  not  referenced 
on  any  structure  or  path.  An  element  is  said  to  be  referenced  on  a 
structure  or  path  if  the  element  name  is  used  in  any  of  the  following 
contexts  in  a structure  or  path: 
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1 ) as  an  element  node 


2)  within  a Boolean  expression 

3)  within  a consider-entity-type  list 

4)  as  a consider-subject 

5)  as  a for-each-subject 

6)  as  a for-each-object 

7)  as  a select-subject 

If  an  element  has  values  for  one  or  more  attributes,  it  is  not 
necessary  to  remove  these  values  before  deleting  the  element.  If  an 
element  has  relationships  to  other  elements,  these  relationships  must 
be  removed  by  modifying  either  the  element  itself  or  the  elements  to 
which  it  is  related  before  the  element  may  be  deleted.  If  an  element  has 
a path  or  structure,  that  path  or  structure  must  be  removed  by  modifying 
the  element  before  the  element  may  be  deleted.  If  an  element  is 
referenced  on  a path  or  structure,  either  the  path  or  structure  must  be 
changed  using  the  Interactive  R-Net  Generation  Function  (see  Section  5.2) 
to  remove  the  reference  or  the  element  with  which  the  path  or  structure 
is  associated  must  be  modified  to  remove  the  path  or  structure,  before  the 
element  may  be  deleted. 

Once  the  necessary  modifications  have  been  performed,  the  element  is 
deleted  by  specifying  the  word  DELETE  followed  by  the  element  type  name 
and  element  name.  Since  this  sentence  results  in  the  complete  removal  of 
all  information  about  the  element  deleted,  it  is  meaningless  to  follow  it 
with  any  attribute,  relationship,  path,  or  structure  declarations. 

An  element  defined  as: 

DEFINE  ALPHA  DUMMY  (*DUMMY  COMMENT*), 
may  be  simply  deleted  by: 

DELETE  ALPHA  DUMMY. 

Formally,  the  syntax  for  deleting  an  element  is: 

<element  deletions  : = 

DELETE  element-type-name  element-name. 

J 
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A comment  may  be  specified  following  the  element  name  but  it  will  result 
in  an  informative  diagnostic  and  the  comment  will  be  Ignored. 

i 

5. 1.3.1  Deleting  an  Element  with  Attribute  Values 

No  special  action  need  be  taken  to  remove  attribute  values  for  an 
element  before  the  element  may  be  deleted.  This  is  true  because  attributes 
are  considered  to  be  strictly  local  to  an  element,  i.e.,  they  affect  no 
other  element,  and  therefore  their  automatic  removal  on  deletion  of  the 
element  does  not  in  any  way  affect  the  definition  of  any  other  element. 

The  user  is,  of  course,  always  free  to  explicitly  remove  any  or  all  attributes 
of  the  element  before  deleting  it.  Section  5. 1.2. 3 of  this  document  dis- 
cussed  the  process  of  removing  attribute  values  for  an  element. 

For  example,  if  DATA  XYZ  is  defined  as: 

DEFINE  DATA  XYZ  (*XYZ  COMMENT*). 

DESCRIPTION  "STRICTLY  FOR  AN  EXAMPLE". 

IN  IT IAL_yALUE  -37.315E-38. 

MAXIMUM_VALUE  0.0  (*MUST  NOT  BE  > 0*). 

then 

MODIFY  DATA  XYZ. 

REMOVE  DESCRIPTION. 

REMOVE  IN  IT IAL_VALUE . 

REMOVE  MAXIMUM_VALUE. 

DELETE  DATA  XYZ. 

is  exactly  equivalent  to: 

DELETE  DATA  XYZ. 

Both  forms  will  completely  remove  XYZ,  its  comment,  and  all  of  its 
attribute  values  and  their  comments.  The  net  result  will  be  exactly 
the  same  as  if  DATA  XYZ  was  never  defined. 

5. 1.3. 2 Deleting  an  Element  with  Relationships 

Before  an  element  may  be  deleted,  all  relationships  between  that 

[element  and  all  other  elements  must  be  explicitly  removed.  This  may  be 
accomplished  by  modifying  the  element  to  remove  the  relationships  or  by 
modifying  the  elements  to  which  the  element  is  related.  The  user  is 
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referred  to  Section  5. 1.2. 5 for  a discussion  of  the  removal  of  relation- 
ships between  elements. 

For  example,  if  DATA  XYZ  is  defined  as  follows: 

DATA  XYZ. 

INCLUDES  DATA  X 
DATA  Y 
DATA  Z. 

INPUT  TO  ALPHA  ALF1 . 

then  the  INCLUDES  and  INPUT  relationships  must  be  removed  before  DATA  XYZ 
may  be  deleted.  The  following  modifies  X,  Y,  Z and  ALF1  to  remove  these 
relationships  and  then  deletes  XYZ. 

MODIFY  DATA  X. 

REMOVE  INCLUDED  IN  XYZ. 

MODIFY  DATA  Y. 

REMOVE  INCLUDED  IN  XYZ. 

MODIFY  DATA  Z. 

REMOVE  INCLUDED  IN  XYZ. 

MODIFY  ALPHA  ALF1 . 

REMOVE  INPUTS  XYZ. 

DELETE  DATA  XYZ. 

DATA  XYZ  could  also  have  been  modified  directly  to  remove  the  relationships 
and  then  deleted: 

MODIFY  DATA  XYZ. 

REMOVE  INCLUDES  DATA  X. 

REMOVE  INPUT  TO  ALF1 . 

REMOVE  INCLUDES  Y,Z. 

DELETE  DATA  XYZ. 

In  either  case,  the  element  XYZ,  its  comment  and  all  relationships  to 
other  elements  will  be  completely  removed  from  the  data  base. 

5. 1.3. 3 Deleting  an  Element  with  a Path  or  Structure 


If  an  element  has  an  associated  path  or  structure,  the  path  or 
structure  must  be  removed  before  the  element  may  be  deleted.  This  may  only 
be  done  by  explicitly  modifying  the  element  to  remove  the  path  or  structure 
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as  described  in  Sections  5. 1.2. 7 and  5. 1.2. 8 of  this  document  or  by  using 
the  RNETGEN  function  (see  Section  5.2). 

For  example,  suppose  that  SUB1  is  defined: 

SUBNET  SUB1  (*HAS  A STRUCTURE*). 

STRUCTURE 

CONSIDER  DATA  DAT1 
IF  (*0R  NODE*) 

(VAL  1 OR  VAL2)  ALPHA  AL1 
OR 

(VAL3)  ALPHA  AL2 
SUBNET  SUB3 
END 

RETURN  (*BACK  TO  CALLING  STRUCTURE*) 

END. 

Then,  the  following  RSL  commands  would  delete  SUB1: 

MODIFY  SUBNET  SUB1 . 

REMOVE  STRUCTURE. 

DELETE  SUBNET  SUB1. 

Again,  suppose  that  VAL1  is  defined  as: 

VALIDATION_PATH  VAL1  (*HAS  A PATH*). 

PATH 

EVENT  EVT01 
EVENT  EVT02 

OUTPUTJNTERFACE  RECORDER 

END. 

Then  VAL1  may  be  deleted  by  entering: 

MODIFY  VALIDATION_PATH  VAL1 . 

REMOVE  PATH. 

DELETE  VALIDATION_PATH  VAL1  . 

5. 1.3. 4 Deleting  an  Element  Referenced  on  a Path  or  Structure 

As  long  as  at  least  one  path  or  structure  contains  a reference  to 
a particular  element,  that  element  cannot  be  deleted.  Therefore,  in  order 
to  delete  an  element  referenced  on  a path  or  structure,  it  is  first 
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necessary  to  remove  that  reference.  A removal  of  the  reference  may  be 
accomplished  by  using  the  Interactive  R-Net  Generation  function  to  physically 
alter  the  structure  or  path,  or  by  using  RSL  commands  to  remove  the  entire 
referencing  structure  or  path.  The  use  of  the  Interactive  R-Net  Generation 
function  Is  detailed  In  Section  5.2. 

In  the  example  below,  RSL  commands  are  used  to  remove  the  structure 
and/or  path  which  references  the  element  to  be  deleted.  Assume  R_NET  NET01 
and  VALIDATION_PATH  VALPATH01  are  defined  as: 

R_NET  NET01 . 

STRUCTURE 

EVENT  EVT01  (*TRIGGER  NET02*) 

ALPHA  ALF1 

VAL IDAT I 0N_P0 I NT  VALP0INT_01 

TERMINATE 

END. 

VALIDATION_PATH  VALPATH_01 . 

PATH 

EVENT  EVTOO 

EVENT  EVT01 

VALIDATION  POINT  VALPOINT  01 


If  the  deletion  of  ALF1  is  desired  then  only  the  structure  for  NET01  must 
be  removed: 

MODIFY  R_NET  NET01 . 

REMOVE  STRUCTURE. 

DELETE  ALPHA  ALF1 . 

If  the  deletion  of  EVT01  or  VALP0INT_01  were  desired  then  both  the  structure 
and  the  path  would  have  to  be  removed.  For  example: 

MODIFY  R_NET  NET01 . 

REMOVE  STRUCTURE. 

MODIFY  VALIDATION_PATH  VALPATHJ31 . 

REMOVE  PATH. 

DELETE  VALIDATION  POINT  VALPOINT  01 . 
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5.1.4  Renaming  an  Element 

The  name  of  any  element  may  be  changed  to  a new  name  as  long  as  that 
new  name  is  not  currently  in  use.  The  form  of  the  statement  is  the  word 
RENAME  followed  by  the  old  element  name,  the  word  AS,  the  new  element  name 
and  an  optional  comment.  Any  existing  comment  for  the  element  will  be 
removed.  If  a new  comment  is  specified  it  will  be  associated  with  the  new 
element  name. 

For  example,  assume  that  0LD_ELT  was  declared  as: 

ALPHA  0LD_ELT  (COMMENT  FOR  0LD_ELT*) . 

then 

RENAME  0LD_ELT  AS  NEW_ELT. 

will  result  in  the  following  information  content  in  the  data  base: 

ALPHA  NEW_ELT . 

The  rename  command  is  equivalent  to  a modification  of  an  existing 
element  definition.  Thus  the  rename  command  should  only  be  specified 
between  element  definitions,  not  within  the  declarations  of  any  element 
definition. 

Formally,  the  syntax  for  a rename  is: 

<RSL  comma nd>::= 

RENAME  element-name  AS  new-element-name  [comment]. 

Cautions  for  Renaming 

The  user  should  be  aware  that  renaming  an  element  will  not  change 
the  name  in  material  which  is  stored  in  the  data  base  in  the  form  of 
character  strings.  The  following  are  stored  in  this  form: 

1.  All  comments,  i.e.,  material  enclosed  within  the  comment 
brackets  (*  and  *). 

2.  All  text  strings,  i.e.,  material  enclosed  within  the  text 
brackets  " and  ".  Note  that  this  includes  all  code  within 
the  executable  description  (BETA  or  GAMMA  attribute  value) 
for  an  ALPHA  as  well  as  the  code  within  a TEST  attribute 
value  for  a PERFORMANC E_REQUIREMENT. 

3.  All  conditionals  in  structures,  i.e.,  material  enclosed 
within  the  conditional  brackets  ( and  ). 
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5.1.5  Retyping  an  Element 

The  element  type  of  any  element  may  be  changed  as  long  as  the  new 
type  is  compatible  with  all  current  uses  of  the  element.  This  means  that 
the  following  must  all  be  true: 

1.  All  attributes  for  the  element  must  be  legal  for  the  new 
element  type. 

2.  All  relationships  the  element  has  must  be  legal  for  the 
new  element  type. 

3.  All  references  to  the  element  on  structures  and  paths  must 
be  in  a context  which  is  allowable  for  the  new  element  type. 

4.  The  element  must  not  have  an  associated  structure  or  path. 

An  element  is  retyped  by  specifying  the  word  RETYPE,  the  element 
name,  the  word  AS,  and  the  new  element  type  name.  Like  a rename,  the  retype 
command  is  equivalent  to  a modification  of  an  existing  element  definition 
and  should  only  be  specified  between  element  definitions,  not  within  the 
declarations  of  any  element  definition. 

Assume  that  the  following  element  definitions  exist: 

ALPHA  AL  (*THIS  IS  ALPHA  AL*). 

DESCRIPTION  "GOODJLD  AL". 

DATA  DAT1 . 

INITIAL_VALUE  -5.0. 

SUBNET  SUB1  (COMMENT  FOR  SUB1*). 

STRUCTURE 
ALPHA  X 
SUBNET  Y 
RETURN 


The  following  retype  would  be  acceptable  since  the  attribute  DESCRIPTION  is 
legal  for  DATA. 

RETYPE  AL  AS  SUBNET. 

The  resulting  definition  of  AL  is: 

SUBNET  AL  (*THIS  IS  ALPHA  AL*). 

DESCRIPTION  "GOOD  OLD  AL". 
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The  following  two  retypes  would  not  be  acceptable;  the  first  because  a 


FILE  cannot  have  an  INITIAL_VALUE  and  the  second  because  SUB1  has  an 
associated  structure. 

RETYPE  DAT1  AS  FILE. 

RETYPE  SUB1  AS  R_NET. 

Formally,  the  syntax  for  a retype  is: 

<RSL  command>::= 

RETYPE  element-name  AS  element-type-name. 

5.1.6  Using  Synonyms 

The  user  may  define  an  alternate  name  for  an  element  by  introducing 
another  element  of  type  SYNONYM  and  the  relationship  EQUATES  between  the 
two  elements.  A synonym  name  EQUATES  to  at  most  one  element  name,  termed 
the  prime  name.  However,  a single  element  name  may  be  EQUATED  to  any 
number  of  synonym  names.  For  example,  the  following  EQUATES  SYN1  and  SYN2 
to  the  prime  name  AL1 : 

DEFINE  ALPHA  AL1 . 

EQUATED  TO  SYNONYM  SYN1 , 

SYNONYM  SYN2. 

Once  a synonym  name  has  been  defined  and  EQUATES  to  a prime  name,  any 
reference  to  the  synonym  name  is  interpreted  as  a reference  to  the  prime 
name.  The  one  exception  to  this  rule  is  when  the  element  type  name  SYNONYM 
is  stated  explicitly. 

If  the  intended  reference  is  to  the  prime  name,  the  element  type  name 
for  the  prime  name  should  be  used.  Thus,  given  the  definitions  of  AL1 , 

SYN1  and  SYN2  above,  the  following  two  structures  are  exactly  equivalent. 

SUBNET  SUB1 . 

STRUCTURE 

ALPHA  SYN1 
SUBNET  SUB2 
ALPHA  AL1 
RETURN 

END. 


SUBNET  SUB! . 

STRUCTURE 
ALPHA  AL1 
SUBNET  SUB2 
ALPHA  SYN2 
RETURN 

END. 

To  declare  a synonym  name  or  EQUATES  relationship,  or  to  remove  such 
declarations,  the  element  type  name  SYNONYM  must  be  used.  Given  the  above 
definitions  of  AL1 , SYN1 , and  SYN2,  the  EQUATES  relationships  may  be 
removed  by  stating. 

MODIFY  ALPHA  A1 . 

REMOVE  EQUATED  TO  SYNONYM  SYN1 
SYNONYM  SYN2. 

The  synonym  element  SYN1  and  SYN2  may  then  be  deleted: 

DELETE  SYNONYM  SYN1 . 

DELETE  SYNONYM  SYN2. 

Note  that  if  the  element  type  name  SYNONYM  had  not  been  stated  explicitly, 
the  modification  above  would  have  been  interpreted  as: 

MODIFY  ALPHA  A1  . 

REMOVE  EQUATED  TO  ALPHA  A1 
ALPHA  A1 . 


which  is  illegal . 


Cautions  on  the  Use  of  Synon\ 


Synonyms  should  not  be  used  in  any  material  which  is  stored  in  the 
data  base  in  the  form  of  character  strings.  The  following  are  stored  in 
this  form: 


1.  Comments,  i.e.,  material  enclosed  within  (*  and  *). 

2.  Text  strings,  i.e.,  material  enclosed  within  double  quotes. 
This  includes  all  BETA  and  GAMMA  attribute  values  for  ALPHAS 
and  TEST  attribute  values  for  PERFORMANCE_REQUIREMENTs. 

3.  Conditionals  in  structures,  i.e.,  material  enclosed  within 
( and  ). 
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This  section  describes  the  Interactive  R-Net  Generation  function 
(RNETGEN)  which  provides  an  interactive  (prompting)  graphics  method  of 
creating  and  storing  into  the  ASSM  the  structures  for  R_NETs,  SUBNETS,  and 
VALIDATION_PATHs . This  interactive  graphics  facility  is  only  available 
when  REVS  is  operating  in  the  on-line  mode  (see  Section  4.3)  and  uses  the 
ANAGRAPH  color  graphics  terminal  for  displaying  and  manipulating  a graphical 
representation  of  such  structures.  Figure  5-1  presents  a typical  SUBNET 
structure  as  displayed  on  the  screen.  |j 

The  Interactive  R-Net  Generation  function  is  invoked  by  issuing  the 
RCL  statement,  RNETGEN.  REVS  must  be  in  the  on-line  mode  prior  to  issuing 
this  RCL  statement.  Should  the  RNETGEN  statement  be  issued  in  the  off- 
line mode,  an  appropriate  diagnostic  message  will  be  generated  in  the 
REVS. OUT  file,  and  processing  will  continue  with  the  next  RCL  statement. 

Upon  successful  processing  of  the  RNETGEN  statement,  the  message  "ENTER 
TRACKBALL  TO  CONTINUE"  is  displayed  on  the  screen.*  The  user  must  respond 
by  depressing  the  trackball  entry  key  in  order  for  RNETGEN  to  continue. 

The  screen  is  subsequently  erased  and  redrawn  with  a menu  appearing  along 
its  left  side  as  depicted  in  Figure  5-1. 

This  menu  list  consists  of  the  basic  operations  provided  by  the 
RNETGEN  function.  Any  one  of  these  operations  is  invoked  by  selecting 
the  appropriate  menu  line  entry  via  the  trackball  input  facility  (i.e., 
the  trackball  cursor  is  positioned  on  the  menu  line  and  the  trackball 


entry  key  depressed).  The  last  selected  menu  line  remains  in  force 
(active)  until  overridden  by  a subsequent  menu  selection;  the  white  bullet 
marker  appearing  at  the  left  edge  of  each  menu  line  is  colored  red  for  the 
currently  active  menu  selection. 

Depending  upon  the  current  status  of  RNETGEN,  the  selection  of  a 
particular  operation  may  be  illegal  and  result  in  the  message  "ILLEGAL 
MENU  SELECTION".  For  example,  prior  to  building  or  retrieving  a structure, 
user  selection  of  the  MOVE  NODE  menu  operation  would  be  illegal.  In 
such  cases  the  diagnostic  message  is  displayed,  the  input  request  is 
ignored,  and  some  other  menu  operation  must  be  selected  by  the  user. 


*A11  of  the  messages  displayed  by  RNETGEN  are  listed  and  described  in 
Appendix  E. 


MENU 

■ STRUCTURE  TYPES 


Figure  5-1  RNETGEN  Display 


The  color  menu  appearing  below  the  menu  list  provides  the  capability 
for  specifying  a color,  of  which  there  are  seven,  to  be  used  in  displaying 
nodes  on  the  structure.  A more  detailed  description  of  color  selection  is 
given  in  Section  5. 2. 2. 8.  The  currently  active  color  selection  is  indicated 
with  either  a small  solid  or  outlined  black  square  located  in  the  center  of 
the  selected  color  square.  Turquoise  is  the  default  color  selection  pro- 
vided by  RNETGEN  initiation. 

5.2.1  Identifying  the  Structure 

There  are  three  types  of  structures  which  may  be  created  and  stored 
or  retrieved  and  modified  by  the  RNETGEN  function.  As  indicated  in  the 
menu,  these  are  R_NET,  SUBNET,  and  VALIDATION_PATH  structures.  Upon 
selection  of  one  of  these  menu  entries,  the  message  "KEYIN  ELEMENT  NAME  OF 
DESIRED  ELEMENT"  is  displayed  just  below  the  color  menu  display.  The  user 
responds  to  this  message  by  typing  in  the  name  of  the  element  to  which  the 
desired  structure  is  (or  is  to  be)  attached.  If  the  name  is  illegal  (i.e., 
the  name  does  not  begin  with  an  alphabetic  character  and  contains  characters 
other  than  alphanumeric  or  the  underscore),  then  the  message  "ILLEGAL 
SYNTAX,  INPUT  REJECTED"  is  displayed  and  the  input  is  rejected.  If  the 
name  is  already  in  use  in  the  ASSM,  but  for  some  other  purpose,  then  an 
appropriate  message  is  displayed  and  the  user  input  is  rejected.  In  either 
case,  the  user  must  re-issue  a menu  selection  to  continue. 

However,  if  the  input  name  already  exists  in  the  ASSM  as  an  element 
of  the  appropriate  type  (R_NET,  SUBNET,  or  VALIDATION_PATH) , then  the 
message  "ELEMENT  IN  ASSM,  IS  IT  THE  ONE?  KEYIN  YES  OR  NO"  is  displayed. 

The  user  responds  with  a keyboard  entry  of  YES  (Y)  or  NO  (N).  If  the 
response  is  NO  then  the  input  name  is  ignored  and  another  menu  selection 
must  be  issued  to  continue. 

If  the  response  is  YES  and  a structure  already  exists  in  the  ASSM, 
it  will  be  copied  to  a temporary  work  area  in  the  ASSM.  The  user  will  then 
be  given  the  option  to  display  the  structure  in  either  its  zoomed-in  or 
zoomed-out  mode  (see  Section  5.2.3).  The  message  "ZOOM-OUT  OR  ZOOM-IN  ON 
STRUCTURE,  SELECT  VIA  TRACKBALL"  is  displayed.  The  user  responds  by  using 
the  trackball  to  select  the  word  ZOOM-OUT  or  the  word  ZOOM-IN  in  the 
displayed  message.  The  structure  will  then  be  displayed  accordingly. 
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If  the  structure  contains  no  graphics  coordinate  data  (i.e.,  the 
structure  was  created  and  stored  in  the  ASSM  via  the  RSL  translator),  then 
the  user  will  be  given  the  option  to  use  either  the  autoplot  capability  or 
the  prompting  capability  for  entering  graphics  coordinate  data  on  the 
structure.  The  message  "NO  GRAPHICS  DATA  ON  STRUCTURE"  is  displayed  followed 
by  the  message  "SELECT  - PROMPTER  OR  AUTOPLOT  - VIA  TRACKBALL".  The  user 
responds  with  a trackball  selection  of  either  PROMPTER  or  AUTOPLOT.  If  the 
autoplot  mode  is  selected,  all  graphics  coordinates  for  each  node  on  the 
structure  are  generated  automatically  and  the  user  is  then  given  the  option 
to  display  the  resulting  structure  in  either  its  zoomed-out  or  its  zoomed-in 
mode.  If  the  user  selects  the  prompting  mode  for  entering  graphics  coordinate 
data,  then  the  entry  node  of  the  structure  is  displayed  at  the  top  center  of 
the  screen  display  area  and  the  message  "USE  SUCCESSOR  NODE  MENU  SELECTION 
FOR  PROMPTING"  is  displayed  below  the  menu  list.  A detailed  description  of 
this  operation  is  given  in  Section  5. 2. 3. 7. 

If  the  ASSM  element  does  not  contain  an  associated  structure,  then 
an  entry  node  for  the  structure  is  created  and  displayed  at  the  top  center 
of  the  display  area.  The  user  continues  by  making  some  other  menu  selection 
in  order  to  add  to  the  structure.  The  following  section  describes  these 
operations  in  detail . 

If  the  element  input  name  does  not  exist  in  the  ASSM  the  user  will  be 
informed  by  the  message  "ELEMENT  NOT  IN  ASSM,  DO  YOU  WANT  IT  ENTERED? 

KEYIN  YES  OR  NO".  If  the  response  is  NO  then  the  input  name  is  ignored  and 
another  menu  selection  must  be  issued  to  continue.  If  the  user  response  is 
YES  then  the  element  name  is  entered  in  the  ASSM  and  an  entry  node  for  its 
structure  is  created  and  displayed  at  the  top  center  of  the  screen  display 
area.  Again,  the  user  continues  by  making  other  menu  selections  in  order 
to  add  to  the  structure. 

5.2.2  Creating/Modifying  a Structure 

Once  a structure  or  any  portion  thereof  has  been  displayed  on  the 
screen  in  its  zoomed-in  mode,  it  may  be  altered  through  the  use  of  any 
of  the  menu  operations  described  in  the  following  subsections.  It  should 
be  pointed  out,  however,  that  any  changes  made  are  only  temporary.  Once 
the  user  has  made  all  desired  changes,  the  SAVE  NET  menu  operation  must 


5-46 


/ 


be  selected  in  order  for  the  altered  structure  to  become  permanent  in 
the  ASSM. 

5.2.2. 1 Adding  a Node 

To  add  a node  to  the  currently  displayed  structure  the  user  must 
first  select  the  desired  node  type  from  the  list  of  available  node  types 
appearing  in  the  menu.  If  the  selected  node  type  is  illegal  for  the 
current  structure,  the  message  "ILLEGAL  NODE  FOR  CURRENT  STRUCTURE"  will 
be  displayed  and  the  selection  will  be  rejected.  After  successfully 
selecting  a node  type,  the  node  is  positioned  in  the  structure  display 
area.  This  is  accomplished  by  selecting  a point  on  the  screen  via  the 
trackbal 1 . 

One  of  two  errors  may  result  from  this  operation.  If  the  selected 
point  is  too  close  to  an  already  existing  node,  possibly  causing  a node 
overlap,  the  message  "NODE  OVERLAP  IN  STRUCTURE,  REPEAT  SELECTION  SEQUENCE" 
will  be  displayed  and  another  screen  position  must  be  selected  by  the  user. 

Also,  if  the  selected  point  is  too  close  to  the  border  of  the  screen  display 
area,  the  message  "NODE  WILL  NOT  FIT  ON  DRAWING  AREA,  TRY  AGAIN"  may  result 
and  a new  position  will  have  to  be  selected. 

If  the  selected  node  type  references  an  element  in  the  ASSM,  the 
message  "KEYIN  DESIRED  ELEMENT  NAME"  will  be  displayed;  the  user  responds 
with  a keyboard  input  of  the  appropriate  name.  If  an  input  error  is 
detected  (i.e.,  a name  syntax  error  or  the  element  is  already  in  the  ASSM 
with  inappropriate  type),  then  the  input  is  ignored,  and  the  user  must 
restart  the  input  sequence  by  re-selecting  the  node  screen  position.  If 
the  element  name  is  not  in  the  ASSM,  the  user  is  given  the  option  to 
either  enter  it  or  not  enter  it  in  the  ASSM.  This  is  done  by  keying  in 
YES  (Y)  or  NO  (N)  in  response  to  the  message  "ELEMENT  NOT  IN  ASSM,  DO 
YOU  WANT  IT  ENTERED?  KEYIN  YES  OR  NO". 

If  the  selected  node  type  is  an  OR  node,  the  message  "CONSIDER  - DATA, 
ENTITYjCLASS,  NEITHER  - SELECT  VIA  TRACKBALL"  Is  displayed  and  the  user 
must  respond  by  selecting  one  of  the  three  entries  in  the  message  via  the 
trackball.  If  the  selection  is  either  DATA  or  ENTITY_CLASS,  the  user  will 
be  required  to  enter  the  corresponding  element  name  via  the  keyboard. 

Again,  checks  are  made  to  ensure  error-free  input.  If  the  supplied  name 
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does  not  exist  in  the  ASSM,  an  option  will  be  given  to  allow  entry  into 
the  ASSM. 

If  the  selected  node  type  is  a FOR  EACH  node,  the  message  “FOR  EACH  - 
FILE,  ENTITYJYPE,  OR  ENTITY_CLASS  - SELECT  VIA  TB"  is  displayed.  The  user 
must  respond  with  a trackball  selection  of  the  appropriate  element  type 
from  the  list  within  the  message.  The  corresponding  element  name  is  then 
keyed-in  and  similar  processing  is  performed  as  with  the  OR  node. 

Once  all  required  inputs  have  been  supplied,  error-free,  the  indicated 
node  type  symbol  is  displayed  at  the  selected  point  on  the  screen.  If  the 
node  references  an  element,  the  first  three  (3)  characters  of  the  element 
name  are  also  displayed  with  the  node  symbol  on  the  screen.  Figure  5-2 
gives  a list  of  the  avail  e node  types  and  their  corresponding  display 
symbol s. 

5. 2. 2. 2 Removing  a Node 

Any  node  may  be  removed  from  the  current  structure  by  first  selecting 
the  DELETE  NODE  menu  operation  and  subsequently  using  the  trackball  to 
point  to  the  desired  node  on  the  displayed  structure.  If  the  message  “NON- 
EXISTENT NODE  SELECTED,  RESTART  SELECTION  SEQUENCE"  appears,  the  user  has 
not  correctly  specified  a node  on  the  structure.  This  condition  can  happen 
if  the  trackball  cursor  is  not  properly  positioned  on  the  node,  i.e.,  try 
to  place  it  as  close  as  possible  to  the  node's  center.  When  the  node  has 
been  properly  identified,  it  will  be  erased  from  the  screen  along  with  all 
of  its  connecting  arcs.  The  corresponding  information  will  also  be  removed 
from  the  ASSM  and  an  appropriate  message  will  be  displayed  to  inform  the 
user  that  the  operation  is  complete. 

5. 2. 2. 3 Connecting  Nodes 

Node  arcs  are  formed  by  first  selecting  the  CONNECT  NODES  menu  opera- 
tion and  subsequently  using  the  trackball  to  indicate  the  predecessor  node 
and  its  corresponding  successor  node.  Checks  are  performed  to  determine 
if  nodes  do  indeed  exist  at  the  selected  points  on  the  screen  and,  if  so, 
whether  the  indicated  nodes  can  be  legally  connected.  If  an  error  condi- 
tion exists,  the  message  "ILLEGAL  NODE  SELECTION,  RESTART  SELECTION  SEQUENCE" 
is  displayed.  If  either  one  of  the  selected  nodes  is  found  to  be  in  error, 
both  nodes  must  be  re-selected  in  order  to  continue.  If  the  selected 
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Figure  5-2  Node  Display  Symbols 
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predecessor  node  is  an  OR  node  and  an  implicit  determination  cannot  be 
made  as  to  its  type  (e.g.,  splitting  or  rejoining  OR  node),  then  the  user 
must  respond  YES  (Y)  or  NO  (N)  to  the  displayed  message  "IS  PREDECESSOR 
NODE  A REJOINING-OR-NODE,  KEYIN  YES  OR  NO". 

If  the  predecessor  node  is  a splitting  CONSIDER  OR  node,  then  one 
of  the  two  following  messages  will  be  displayed: 

1)  KEYIN  ENTITY  TYPE  ELEMENT(S)  ASSOCIATED  WITH  THIS  BRANCH 
( ) or 

2)  KEYIN  RANGE  VALUE(S)  ASSOCIATED  WITH  THIS  BRANCH  ( ). 

The  user  responds  by  entering,  via  the  keyboard,  the  requested  branch  in- 
formation enclosed  within  parentheses.  The  branch  conditions  have  the 
same  syntax  as  RSL  branch  conditions  (see  Section  5. 1.1. 4).  Syntax  and 
semantic  checks  are  performed  on  this  input  and  if  an  error  is  detected, 
an  appropriate  diagnostic  message  is  displayed  and  all  inputs  are  ignored 
including  node  selections.  Node  selections  must  be  re-issued  in  order  to 
continue. 

If  the  predecessor  node  is  a splitting  non-CONSIDER  OR  node  and  the 
branch  requires  an  ordinal,  then  the  message  "KEYIN  ORDINAL  VALUE"  is  dis- 
played. The  user  must  then  key  in  a four  character  (numeric)  value  to  be 
attached  to  the  indicated  branch.  Checks  are  performed  on  the  input  to 
insure  correctness.  If  an  error  is  detected  (i.e.,  non-numeric  value  or 
duplicate  ordinal),  then  an  appropriate  diagnostic  is  displayed  and  the 
ordinal  value  must  be  keyed  in  again.  Once  the  ordinal  value  has  been 
input  without  error  or  if  no  ordinal  is  required  for  the  indicated  branch, 
then  the  message  "ENTER  CONDITIONAL  EXPRESSION  SEGMENT"  will  be  displayed. 
The  user  must  respond  by  typing  in  the  conditional  expression  enclosed 
within  parentheses.  If  the  conditional  expression  is  the  word  OTHERWISE, 
then  the  parentheses  are  omitted  on  input. 

If  the  predecessor  node  is  a FOR  EACH  node,  the  user  is  given  the 
option  to  supply  a conditional  expression  to  be  attached  to  the  branch. 

After  successfully  supplying  all  input  required  to  form  the  arc 
between  the  selected  nodes,  a white  directed  arc  is  displayed  on  the 
structure  and  the  corresponding  information  is  entered  in  the  ASSM.  An 
appropriate  message  is  displayed  to  inform  the  user  that  the  menu  operation 
has  been  successfully  completed. 
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5. 2. 2. 4 Disconnecting  Nodes 

Node  arcs  are  removed  from  the  structure  via  the  DISCONNECT  NODES 
menu  operation.  This  is  accomplished  by  using  the  trackball  to  identify 
the  two  nodes  on  the  structure  which  are  to  be  disconnected.  Error  checks 
are  performed  to  ensure  that  the  selected  nodes  do  indeed  exist  on  the 
structure  and  that  they  do  have  arcs  between  them.  If  an  error  is  detected, 
an  appropriate  message  is  displayed  and  the  node  selection  sequence  must  be 
restarted.  It  should  be  pointed  out  that  the  node  selection  sequence  is 
irrelevant  ( i . e . , either  the  successor  or  predecessor  node  may  be  selected 
first).  Upon  successful  identification  of  the  two  nodes,  the  node  arc  is 
erased  from  the  screen  and  the  corresponding  information  is  removed  from 
the  ASSM.  If  the  deleted  branch  was  an  OR  or  FOR  EACH  branch  containing  a 
conditional  expression  then  this  information  is  also  removed  from  the  ASSM. 
After  successful  completion  of  the  operation,  an  appropriate  message  is 
displayed  to  inform  the  user  that  he  may  continue  with  other  operations. 

5. 2. 2. 5 Commenting  a Node 

The  COMMEND  NODE  menu  operation  is  multipurpose  in  that  it  allows  the 
user  to  enter,  remove,  or  display  comments  on  a node  in  the  structure.  After 
identifying  the  desired  node  using  the  trackball,  the  message  "ENTER,  REMOVE, 
OR  DISPLAY  COMMENT  ON  NODE,  SELECT  VIA  TB"  is  displayed;  the  user  responds 
with  a trackball  selection  of  the  desired  operation  to  be  performed  on  the 
selected  node. 

If  ENTER  is  selected,  then  the  user  is  required  to  type  in  the  desired 
comment  enclosed  within  (*  and  *).  Upon  completion  of  this  input,  an 
appropriate  message  is  displayed  to  inform  the  user  that  the  operation  has 
been  performed. 

If  REMOVE  is  selected,  the  comment,  if  one  exists,  is  detached  from 
the  selected  node  and  deleted  from  the  ASSM. 

If  DISPLAY  is  selected,  the  first  line  of  the  comment  is  displayed, 
if  one  exists,  and  the  message  "ENTER  TRACKBALL  TO  CONTINUE"  is  displayed 
if  there  are  more  lines  in  the  comment;  otherwise,  the  message  "ENTIRE 
COMMENT  ON  SELECTED  NODE  HAS  BEEN  DISPLAYED"  is  displayed.  If  the  selected 
node  is  not  commented,  an  appropriate  message  is  displayed  to  so  inform 
the  user. 
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5. 2. 2. 6  Moving  a Node 


The  user  may  move  any  node  appearing  on  the  screen  by  selecting  the 
MOVE  NODE  menu  operation.  The  node  to  be  moved  is  identified  via  a track- 
ball selection.  If  the  message  "NON_EXISTENT  NODE  SELECTED,  RESTART 
SELECTION  SEQUENCE"  appears,  the  user  must  re-issue  the  trackball  node 
selection  being  more  careful  to  locate  the  trackball  cursor  as  near  the 
node  center  as  possible.  Once  the  desired  node  has  been  successfully 
identified,  the  message  "SELECT -TO  POSITION-VIA  TRACKBALL"  is  displayed; 
the  user  must  respond  using  the  trackball  to  select  the  point  in  the 
screen  display  area  to  which  the  selected  node  is  to  be  moved. 

This  selection  may  also  result  in  an  error  message.  For  example, 
if  the  selected  point  is  too  close  to  an  existing  node  on  the  structure 
(i.e.,  it  might  result  in  a node  overlap)  or  if  the  point  Is  off  the  display 
area  or  too  close  to  the  display  border  (i.e.,  the  entire  node  could  not 
be  displayed),  an  error  condition  exists  and  an  appropriate  diagnostic 
message  is  displayed.  If  this  happens  the  selection  sequence  must  be 
repeated  beginning  with  the  node  selection. 

After  successfully  identifying  both  the  desired  node  and  its  new 
screen  position,  the  node  along  with  any  arcs  extending  from  it  will  be 
erased  from  its  current  location  on  the  screen  and  will  be  redrawn  with 
its  associated  arcs  at  the  new  position  on  the  screen.  The  ASSM  will  be 
updated  accordingly  and  a message  will  be  displayed  to  inform  the  user 
that  the  operation  has  been  successfully  completed. 

5.2. 2.7  Moving  a Subtree 

This  operation  is  similar  to  the  moving  of  a node  except  that  the 
entire  portion  of  the  structure  below  and  including  the  selected  node 
is  moved.  It  should  be  pointed  out  that  node  overlapping  will  not  be 
diagnosed  in  this  operation  as  it  is  in  the  moving  of  a single  node. 
Depending  on  the  extent  of  the  subtree,  this  operation  will  be  somewhat 
slower  to  complete  than  any  of  the  previously  described  operations.  Once 
the  operation  is  complete,  an  appropriate  message  is  displayed  to  inform 
the  user  that  he  may  continue  further  processing. 

5. 2. 2. 8 Selecting  a Color 

The  color  options  available  to  the  user  appear  as  seven  colored 
squares  just  below  the  last  line  in  the  menu  list  (see  Figure  5-1).  The 

5-52 


selected  color  is  used  for  displaying  nodes  on  the  screen  as  they  are 
created  by  the  user.  It  may  also  be  used  for  changing  a node  color 
appearing  on  the  displayed  structure.  The  desired  color  is  selected  via 
the  trackball  prior  to  selecting  the  node  type  to  be  created  or  prior  to 
selecting  the  node  on  the  structure  whose  color  is  to  be  changed.  So 
long  as  the  selected  color  in  the  menu  is  identified  by  a small  black  out- 
lined square,  the  node  color  change  mode  is  in  effect.  However,  as  soon 
as  any  other  menu  selection  is  made,  the  black  outlined  square  in  the 
color  menu  becomes  a solid  black  square  indicating  that  a color  menu 
selection  is  required  to  re-activate  the  node  color  change  mode. 

The  selected  color  indicated  in  the  menu  is  also  used  by  the  AUTOPLOT 
operation  as  described  in  Section  5. 2. 3. 8 below. 

5. 2. 2. 9 Saving  a Structure 

As  stated  earlier,  the  structure  currently  being  built  or  modified 
resides  in  a temporary  work  area  of  the  ASSM.  If  the  structure  is  to  be 
given  a permanent  status  in  the  ASSM  the  user  must  do  so  explicitly  by 
selecting  the  SAVE  NET  menu  operation.  If  this  is  not  done  prior  to 
terminating  or  beginning  on  another  structure  then  a warning  message  will 
be  issued  to  inform  the  user  that  the  current  structure  was  not  saved; 
the  user  may  save  the  structure  at  this  point. 

Before  the  structure  is  actually  saved,  a structure  analysis  is 
performed  to  determine  whether  there  are  any  errors  existing  in  the 
structure.  If  an  error  is  detected  ( i . e . , an  incomplete  or  incorrect 
structure),  the  structure  is  erased  from  the  screen.  It  is  redisplayed 
with  the  node  in  error  centered  in  the  display  area  with  a red,  white, 
and  blue  square  surrounding  it.  An  appropriate  error  message  is  also 
displayed  explaining  the  cause  of  the  error.  At  this  point  the  user  must 
correct  the  error  before  the  structure  can  be  saved. 

Once  the  structure  has  been  saved,  and  this  may  take  several  seconds 
depending  on  the  size  of  the  structure,  a message  will  be  displayed  to 
inform  the  user  that  the  structure  was  successfully  saved. 

5.2.3  Displaying  a Structure  and  Its  Elements 

A structure  may  be  displayed  on  the  screen  in  one  of  two  modes: 
zoomed-in  mode  or  zoomed-out  mode.  As  stated  previously,  structures  can 
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be  created  and  modified  only  in  the  zoomed-in  mode.  The  zoomed-out  mod'1 
has  been  provided  so  that  the  user  may  view  a structure  in  its  entirety 
in  a miniature  color-coded  form  when  the  structure  is  too  large  to  be 
displayed  in  its  zoomed-in  mode. 

5. 2. 3.1  Scrolling  a Structure 

An  additional  feature  has  been  provided  to  display  any  portion  of 
large  structures  in  the  zoomed-in  mode.  This  is  accomplished  using  the 
SCROLL  NET  menu  operation.  Although  this  operation  has  been  categorized 
as  a display  capability  for  structures  or  portions  thereof,  it  would  and 
does  also  fit  in  the  category  of  functions  used  and  required  in  the  build- 
ing and  modifying  of  structures.  It  provides  a windowing  capability  for  a 
structure  which  is  too  large  to  fit  on  the  screen  in  its  zoomed-in  mode. 

Upon  selection  of  this  menu  operation,  the  user  selects  a "from"  and 
"to"  position  on  the  screen  using  the  trackball.  The  "from"  position 
indicates  a point  on  the  structure  which  is  to  be  moved  across  the  screen 
to  the  "to"  position  on  the  screen.  Upon  selection  of  the  "from"  position, 
a small  blue  solid  circle  is  displayed  serving  as  a reminder  to  the  user 
of  the  selected  point.  Note  that  this  point  must  be  located  in  the  screen 
display  area;  otherwise,  a diagnostic  message  will  be  displayed  and  the 
input  will  be  rejected. 


After  successfully  identifying  the  "from"  and  "to"  positions,  the 
structure  is  erased  from  the  screen  and  redrawn  with  the  "from"  position 
now  located  at  the  "to"  position  on  the  screen.  A message  is  then  dis- 
played to  inform  the  user  that  the  operation  has  been  completed. 

It  should  be  noted  that  no  changes  are  made  to  the  ASSM  as  a result 
of  this  operation.  The  user  may  now  add  to  or  modify  the  structure  using 
any  of  the  previously  described  menu  operations. 


5. 2. 3. 2 Zooming-Out  on  a Structure 

This  menu  operation  may  be  used  on  any  structure  which  is  currently 
displayed  on  the  screen  in  its  zoomed-in  mode.  The  resulting  display 
presents  the  entire  structure  on  the  screen,  regardless  of  its  size,  in 
a color-coded  form.  Following  is  a legend  for  the  nodes  and  their  color- 
coded  representations  on  a zoomed-out  structure  display: 
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Once  a structure  has  been  displayed  in  its  zoomed-out  mode,  none  of 
the  node  manipulation  menu  operations  are  allowed;  should  the  user  attempt 
one  of  these  operations,  an  error  message  will  result  and  the  menu  selection 
will  be  ignored. 

5. 2. 3. 3 Zooming-In  on  a Structure 

This  operation  can  be  used  only  if  a structure  is  currently  displayed 
in  its  zoomed-out  mode  (see  the  preceding  section);  otherwise,  its  selection 
will  result  in  an  error  message  and  the  selection  will  be  ignored. 

If  the  selection  is  allowed,  the  user  responds  by  selecting  a point  on 
the  zoomed-out  structure.  This  point  in  the  structure  will  be  re-displayed 
at  the  top  center  of  the  display  area.  Below  this  will  be  displayed,  in  the 
zoomed-in  mode,  the  remaining  portion  of  the  structure  below  the  selected 
point.  The  user  may  then  continue  to  add  to  or  modify  the  structure  as 
desired . 

5. 2. 3. 4 Displaying  a Node  Element 

As  indicated  previously,  only  the  first  three  characters  of  the  name 
of  an  element  associated  with  a node  are  displayed  on  the  structure.  By 
selecting  the  DISPLAY  NODE  menu  operation  and  subsequently  pointing  to  the 
desired  node  via  the  trackball,  the  user  is  able  to  see  the  entire  element 
name.  It  will  be  displayed  just  below  the  color  menu  line.  If  the  selected 
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node  has  no  element  associated  with  it,  such  as  an  AND  node,  an  appropriate 
message  will  result  and  the  node  selection  is  ignored. 

5. 2. 3. 5 Displaying  a Branch 

Once  the  conditional  expression  on  an  OR/FOR  EACH  node  branch  has  been 
entered  in  the  ASSM,  it  is  no  longer  visible  on  the  displayed  structure. 

When  modifying  a branch  extending  from  an  OR/FOR  EACH  node,  it  may  be 
necessary  to  know  the  associated  conditional  expression.  By  select- 
ing the  DISPLAY  BRANCH  menu  operation,  the  user  may  at  any  time  have  the 
conditional  expression  of  any  branch  displayed.  Following  the  menu  selection, 
the  user  responds  with  trackball  selections  of  the  successor  and  predecessor 
nodes  of  the  desired  branch  on  the  displayed  structure.  If  no  conditional 
expression  exists  for  the  selected  branch,  an  appropriate  message  is  dis- 
played and  the  node  selections  are  ignored.  If  the  branch  has  an  ordinal 
associated  with  it,  the  ordinal  value  will  be  displayed;  the  user  will  then 
be  required  to  respond  with  a trackball  entry  in  order  to  continue.  The 
first  line  of  the  conditional  expression  will  then  be  displayed.  A track- 
ball entry  will  again  be  required  for  display  of  each  subsequent  line  of 
the  conditional  expression.  After  all  lines  of  the  conditional  expression 
have  been  displayed,  an  appropriate  message  is  oisplayed  to  inform  the  user 
that  the  operation  is  complete. 

5. 2. 3. 6 Displaying  a Structure  on  CALCOMP 

Using  the  CALCOMP  menu  operation,  the  user  can  have  the  currently  dis- 
played structure  plotted  on  the  CALCOMP  plotter.  Upon  selecting  this  opera- 
tion, the  message  "DO  YOU  WANT  STANDARD  DOCUMENT  SIZE,  KEYIN  YES  OR  NO" 
will  be  displayed.  The  user  responds  by  keying  in  YES  (Y)  or  NO  (N)  via  the 
keyboard.  If  the  response  is  YES,  the  generated  CALCOMP  plot  will  be 
8-1/2  x 11  inches.  If  the  response  is  NO,  the  user  will  then  be  asked  to 
keyin  the  desired  document  height  and  width  via  the  keyboard.  These  values 
may  be  keyed-in  as  either  integers  or  real  numbers.  A maximum  of  29  inches 
for  the  document  height  and  50  inches  for  the  width  are  allowed.  Any  values 
larger  than  those  will  be  rejected  and  replaced  by  their  respective  maxlmums. 

The  nodes  on  the  plotted  structure  will  retain  the  same  relative 
position  on  the  structure  as  they  appear  on  the  screen.  However,  up  to 
thirty  characters  of  the  element  names  associated  with  each  node  will  be 
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displayed  on  the  plotted  structure.  A legend  page  will  also  be  generated 
for  each  structure  which  has  branches  with  conditional  expressions  and/or 
nodes  with  comments.  These  branches  and  nodes  are  numbered  on  the  structure; 
these  numbers,  with  their  corresponding  conditional  expressions  and/or 
comment,  are  displayed  on  the  legend  page  (see  Figure  5-3). 

When  the  plotting  is  complete,  an  appropriate  message  is  displayed  to 
inform  the  user  that  other  processing  may  be  continued. 

5 . 2 . 3 . 7 Displaying  a Structure  in  the  Prompting  Mode 

Structures  residing  in  the  ASSM  may  or  may  not  contain  graphics  coordi- 
nate data  for  display  on  the  ANAGRAPH  console.  If  a structure  without  graphics 
coordinates  is  retrieved,  the  user  is  given  the  option  to  either  allow  the 
required  coordinate  data  to  be  generated  automatically  or  to  use  the  prompting 
capability  provided  by  the  SUCCESSOR  NODE  menu  operation.  If  the  user  selects 
the  prompting  capability,  the  entry  node  for  the  structure  is  immediately 
displayed  at  the  top  center  of  the  screen  display  area  and  the  user  is 
advised  to  use  the  SUCCESSOR  NODE  menu  operation  for  displaying  subsequent 
nodes. 

Upon  selection  of  the  SUCCESSOR  NODE  operation,  the  user  responds  by 
pointing  to  the  node  on  the  structure  for  which  the  successor  node  has  not 
yet  been  displayed.  If  the  identified  node  has  no  successor  nodes  to  be 
displayed,  an  appropriate  message  results  and  the  node  selection  is  ignored. 

If  the  identified  node  has  more  than  one  successor  node,  all  of  which  are 
not  displayed,  the  user  will  be  informed  as  to  the  number  of  successors  and 
will  be  required  to  depress  the  trackball  entry  key  to  continue.  The  node 
type  of  the  first  successor  node,  or  the  successor  node  if  there  is  only  one 
successor,  is  displayed  and  the  user  is  then  required  to  use  the  trackball 
to  select  a point  on  the  screen  at  which  the  successor  node  is  to  be  dis- 
played. If  the  selected  point  is  too  close  to  an  existing  node  on  the  screen 
and  might,  therefore,  cause  a node  overlap,  then  an  appropriate  message 
results  and  the  inputs  are  rejected.  Also,  if  the  selected  point  is  out- 
side the  screen  display  area  or  too  close  to  the  border  such  that  the 
node,  if  displayed,  would  extend  outside  the  screen  display  area,  an 
appropriate  message  is  displayed  and  the  inputs  are  rejected.  In  either 
case,  the  user  must  re-issue  the  node  selection  in  order  to  continue. 

The  above  process  is  repeated  until  all  nodes  on  the  structure  have  been 
displayed. 
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5. 2. 3. 8 Automatic  Displayin' 
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Structures  which  have  been  generated  or  modified  via  RNET6EN  may  not 
appear  to  be  quite  as  neat  and  well  proportioned  as  one  would  like.  By 
using  the  AUTOPLOT  menu  operation,  one  can  automatically  replace  the 
coordinate  data  such  that  the  resulting  structure  display  is  much  neater 
and  well  proportioned.  This  is  accomplished  by  first  retrieving  the  desired 
structure  from  the  ASSM,  if  it  is  not  currently  displayed,  and  simply 
selecting  the  AUTOPLOT  menu  operation.  It  should  be  pointed  out  that  this 
operation  also  replaces  all  existing  node  colors  with  the  color  identified 
in  the  color  menu.  When  the  operation  is  complete,  the  user  is  given  the 
option  to  display  the  newly  generated  structure  in  either  its  zoomed-in  or 
zoomed-out  mode.  As  described  in  Section  5.2.1,  automatic  plotting  may 
be  done  for  a structure  entered  through  the  RSL  translator. 

5.2.4  Terminating  the  RNETGEN  Function 

The  user  selects  the  STOP  menu  operation  when  ready  to  return  to  the 
REVS  Executive.  If  the  currently  displayed  structure  has  not  been  saved 
since  it  was  created  or  retrieved,  the  following  message  will  be  displayed: 

WARNING  ...  PREVIOUS  STRUCTURE  WAS  NOT  SAVED,  RE-SELECT  MENU 

The  structure  continues  to  reside  in  the  temporary  work  area  and  the  user 
may,  at  this  time,  select  the  SAVE  NET  menu  operation.  If  the  structure 
has  not  undergone  any  changes  since  it  was  last  saved,  then  it  need  not 
be  saved  again,  since  a permanent  copy  already  resides  in  the  ASSM.  However, 
to  terminate,  the  user  will  be  required  to  re-select  the  STOP  operation. 


^07  • “ll  T 


6.0  ANALYZING  AND  DISPLAYING  REQUIREMENTS  (RADX  FUNCTION) 

The  use  of  the  Requirements  Analysis  and  Data  Extraction  (RADX)  func- 
tion is  described  in  this  section.  The  three  major  areas  of  this  generalized 
tool  are  explained  in  detail  in  the  following  sections.  The  define  set 
facility  which  provides  an  ASSM  query  and  Interrogation  capability  and  pro- 
vides a technique  for  identifying  subsets  of  information  to  be  processed  by 
other  RADX  commands  is  described  in  Section  6.1.  The  various  ways  to 
extract  information  from  the  ASSM  and  generate  printed,  punched,  or  plotted 
output  is  presented  in  Section  6.2.  A description  of  the  automated  static 
analysis  performed  by  RADX  is  contained  in  Section  6.3. 

General  information  that  applies  to  all  commands  that  are  input  to  the 
RADX  function  and  an  explanation  of  RADX  output  messages  are  provided  below. 

RADX  Input  Statements 

As  each  RADX  command  is  described  in  subsequent  sections,  the  syntax 
will  be  presented  along  with  an  explanation  of  the  meaning  of  the  command. 

The  command  syntax  presented  is  expressed  in  the  extended  Backus-Naur  Form 
(BNF)  explained  in  Appendix  A.  The  complete  syntax  of  the  RADX  command 
statements  is  summarized  in  Appendix  F.l. 

There  are  some  syntax  and  semantic  rules  which  are  not  easily  defined 
in  syntax  diagrams  or  BNF  notation  and  do  not  warrant  repetition  as 
each  command  is  described;  these  rules  are  summarized  below. 

• A RADX  statement  is  terminated  by  a period  followed  by  a space 
that  is  not  contained  in  a comment  or  text  string. 

• All  RADX  names  (e.g.,  set  name)  must  be  60  or  less  characters 
in  length.  The  first  character  can  be  an  underscore  or  a 
letter.  The  remaining  characters  can  be  an  underscore,  a 
letter,  or  a digit. 

• All  numbers  are  in  standard  PASCAL  form  (See  Appendix  B). 

0 A comment,  a sequence  of  characters  beginning  with  (*  and 
ending  with  *),  may  be  placed  at  any  location  in  a statement. 

For  example,  (*  THIS  IS  A COMMENT  *). 

0 A text  string,  a sequence  of  characters  beginning  and  ending 
with  double  quotes,  may  be  used  only  where  specified  in  the  RADX 
command  syntax. 
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• The  characters  comma,  colon,  and  semicolon  are  optional 

punctuation  marks  that  can  be  used  any  place  in  a statement 
without  changing  the  meaning  of  the  statement. 


• Special  processing  is  given  to  the  SYNONYM  element  type.  If 
a SYNONYM  element  is  named  in  a RADX  command  and  it  EQUATES 
to  another  element,  then  the  other  element  is  used  in  place 
of  the  SYNONYM  element.  For  the  case  that  the  SYNONYM  is  not 
EQUATED,  the  SYNONYM  element  is  used. 

t An  element  name  cannot  be  preceded  by  an  element  type  name  to 
identify  a single  element.  When  an  element  type  name  is  used 
in  a command,  it  is  interpreted  as  a reference  to  all  the 
elements  of  the  element  type. 

Display  of  User's  Command 

A RADX  command  that  is  input  by  the  user  and  the  display  that  results 
from  the  command  are  separated  by  preceding  the  command  with  the  header 

[RADX  COMMAND  = 

and  following  the  command  with  a line  of  underscores  that  is  as  long  as 
the  longest  line  in  the  command.  When  RADX  is  being  executed  on-line,  the 
header  also  serves  as  a prompter  to  indicate  that  an  input  from  the  user 
is  expected. 

Error  Messages 

A summary  of  the  error  messages  that  can  be  issued  by  RADX  is  given 
In  Appendix  F.2.  All  error  messages  have  a standard  first  line  format 
that  has  the  following  general  form: 

*ERR0R  XXXX  description. 

The  XXXX  Isa  unique  four  digit  number  that  relates  to  the  area  of  RADX  that 
detected  the  error  and  description  is  an  explanation  of  the  error. 

Error  messages  issued  by  RADX  can  occur  during  the  translation  of  a 
statement  or  during  the  processing  of  a statement  after  It  is  successfully 
translated.  For  errors  that  occur  during  translation,  an  output  line  is 
displayed  after  the  error  message  to  identify  the  cause  of  the  error.  The 
line  will  contain  the  keyword  SYMBOL  followed  by  the  user's  Input  symbol 
that  caused  the  error.  Error  messages  that  occur  during  the  processing  of 
a statement  have  supplementary  information  following  the  message  when  It 
is  needed  to  further  identify  the  source  of  the  error. 
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A summary  of  the  number  of  error  messages  issued  by  RADX  during  a 
single  execution  of  the  function  is  also  posted  in  the  REVS.LOG  file.  This 
appears  as: 

QQ  001  NUMBER  OF  ERROR  MESSAGES  ISSUED  BY  RADX  = XX. 


r 
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6.1  SUBSETTING  A REQUIREMENTS  DATA  BASE 


The  define  set  facility  of  RADX  provides  a mechanism  to  subset  an 
ASSM  for  the  purpose  of  user-directed  analysis  of  the  data  base  and  user 
selection  of  requirements  information  to  be  subsequently  processed  by 
other  RADX  commands  such  as  LIST  and  PLOT. 

Conceptually,  a RADX  set  is  a named  collection  of  elements  in  the 
ASSM.  There  are  two  basic  types  of  sets  that  can  be  used:  predefined 
sets  and  user  defined  sets. 


Predefined  Sets 

The  predefined  sets  provide  a basic  subsetting  of  the  ASSM.  They 
are  always  defined  and  available  for  reference  when  RADX  is  activated  and 
cannot  be  redefined  ty  the  user.  The  predefined  sets  are: 

§ The  universal  set,  which  is  referred  to  as  ALL  or  ANY,  con- 
tains all  the  elements  in  the  ASSM. 

• Element  type  sets,  which  are  referred  to  by  an  element  type 
name,  contain  all  the  elements  that  are  of  the  named  element 
type. 

• Element  sets,  which  are  referred  to  by  an  element  name,  con- 
tain the  named  element. 

To  illustrate  the  predefined  sets,  assume  that  an  ASSM  contains  only 
the  following  elements: 

ALPHA:  A. 

DATA:  X. 

DATA:  Y. 

When  RADX  is  executed  the  following  sets  would  immediately  be  ready  for  use: 

SET  ALL  = {A,  X,  Y}  SET  A = {A} 

SET  ANY  = {A,  X,  Y}  SET  X = { X> 

SET  ALPHA  = {A}  SET  Y = { Y >. 

SET  DATA  = (X,  Y} 

User  Defined  Sets 

Additional  subsetting  of  the  ASSM  can  be  achieved  by  defining  new 
sets  by  one  of  the  methods  described  in  this  section.  These  new  sets  are 
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referred  to  as  user  defined  sets  and  they  are  specified  using  the  follow- 
ing general  syntax: 


SET  name  = description. 

The  name  given  to  the  set  can  be  any  word  that  is  not  contained  in  the 
ASSM  and  that  is  not  one  of  the  following  keywords:  ALL,  ANY,  SET,  ELEMENT_ 
TYPE,  MULTIPLE,  or  RSL.  Description  specifies  the  condition  for  membership 
in  the  new  set. 

After  a set  is  defined,  a display  is  made  by  RADX  that  tells  the 
number  of  members  that  are  contained  in  the  new  set.  This  will  appear  in 
the  output  as: 

SET  COUNT  = XX. 

Referencing  Sets 

A RADX  set  is  referenced  in  a command  by  the  following  <set  Identifier 
syntax: 

[SET]  name 

The  name  can  be  that  of  a predefined  set  or  a user  defined  set. 

The  syntax  of  the  various  set  description  methods  appearing  In  the 
remainder  of  this  section  use  the  symbol  <set  Identifier  to  designate  a 
set  identifier.  In  the  explanations,  different  terms  for  the  set  identifier 
are  used  to  indicate  the  meaning  of  the  command.  The  terms  used  are: 
existing  set,  first  independent  set,  second  independent  set,  subject  set, 
object  set,  and  candidate  set. 

The  following  are  examples  of  set  identifiers  that  can  be  used  In 
RADX  commands  to  reference  sets: 

ALL 

SET  ALL 
DATA 

SET  DATA 
X 

SET  X. 

Redefining  Sets 

As  previously  mentioned,  a predefined  set  cannot  be  redefined.  How- 
ever, user  defined  sets  can  be  redefined  at  a user's  convenience.  It  is 
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permissible  to  use  a set  as  an  independent  and  dependent  set  in  the  same 
command.  For  example: 

SET  X = SET  X OR  SET  Y. 

In  the  command,  the  contents  of  the  independent  set  X (i.e.,  the 
one  on  the  right  side  of  the  equal  sign)  remains  constant  during  the  pro- 
cessing of  the  command.  When  the  command  is  completed,  the  old  contents 
of  the  set  are  deleted  and  the  new  definition  takes  effect. 

The  following  is  a list  of  the  different  ways  that  a set  can  be 
defined  by  the  user.  They  are  described  in  the  subsequent  subsections. 

• enumeration 

• combination 

• attribute  qualification 

• relationship  qual ification 

• structure  qualification 

• hierarchy  qualification 

This  section  concludes  with  examples  of  how  the  definition  of  sets  can  be 
employed  to  perform  a user-directed  analysis  of  a requirements  data  base. 

6.1.1  Defining  Sets  By  Enumeration 

The  members  of  a set  can  be  defined  as  those  contained  in  another 
set  or  as  the  union  of  a list  of  sets  by  the  following  syntax:  . 


. 1 n 
SET  new-set-name  =<<set  identifier^. 

The  set  identifier  designates  either  a predefined  set  or  a set  defined 
by  the  user  in  a previous  RADX  statement. 

The  statements  given  below  demonstrate  the  use  of  this  technique  for 
defining  sets. 

SET  A = ALPHA,  FILE,  INPUT JNTERFACE. 

SET  B = SET  A,  STATE,  FOUND. 

In  the  first  statement,  set  A will  contain  all  the  elements  in  the 
ASSM  that  are  members  of  the  predefined  element  type  sets  ALPHA,  FILE 
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or  INPUT_INTERFACE.  The  set  B will  contain  elements  that  are  members  of 
the  user  defined  set  A plus  the  two  predefined  element  sets  STATE  and  FOUND. 

6.1.2  Defining  Sets  By  Combination 

A set  can  be  defined  as  the  logical  combination  of  two  existing 
independent  sets  by  a statement  using  the  following  syntax: 

4 AND  j1 

SET  new-set-name  = <set  identifier><OR  > <set  identifiers 

(MINUS^ 

The  set  identifiers  designate  a first  independent  set  and  a second  independent 
set,  respectively.  The  type  of  combination  performed  is  indicated  by  the 
operation  connecting  the  two  independent  sets.  These  operations  are: 

AND  - Set  intersection.  The  members  of  the  new  set  are  those 
that  are  members  of  both  the  first  independent  set  and 
the  second  independent  set. 

OR  - Set  union.  The  members  of  the  new  set  are  those  that  are 
members  of  either  the  first  independent  set  or  the  second 
independent  set. 

MINUS  - Set  difference.  The  members  of  the  new  set  are  those  that 
are  members  of  the  first  independent  set  but  not  the 
second  independent  set. 

The  following  are  examples  of  set  definitions  by  combination. 

SET  ALPHA_DATA  = ALPHA  OR  DATA. 

SET  NETS_IN_X  = R_NET  AND  SET  X. 

SET  ALL_EXCEPT_DECISION  = ALL  MINUS  DECISION. 

6.1.3  Defining  Sets  By  Attribute  Qualification 

The  qualify  by  attribute  statement  provides  the  capability  to  define  a 
set  of  elements  that  have  or  do  not  have  certain  attribute  characteristics. 

The  syntax  of  the  statement  is: 

SET  new-set-name  = <set  identifiers 


attribute  crHerion>. 


The  attribute  criterion  can  be  specified  by  one  of  the  following 

forms: 


1)  attribute-name 

2)  attribute-name  [<relation  operator>]  <value>. 

The  members  of  the  new  set  are  those  members  of  the  subject  set 
(designated  by  the  set  identifier)  that  satisfy  the  attribute  criterion 
in  the  manner  indicated  by  the  connector.  When  a positive  connector  is 
used,  the  members  of  the  new  set  are  those  in  the  subject  set  which  have 
the  characteristics  stated  by  the  attribute  criterion.  If  a negative 
connector  is  used,  then  the  members  of  the  new  set  are  those  in  the  subject 
set  that  do  not  have  the  attribute  criterion. 


A variety  of  terms  are  allowed  to  be  used  as  positive  and  negative 
connectors  to  increase  the  readability  of  RADX  statements.  The  allowable 
terms  are  listed  below: 


positive  connectors 


negative  connectors 


WITH  <positive  connector>  NO 

WHERE  <positive  connector>  NOT 

WHICH  WITHOUT 

WHICH  IS 
IN 

FROM 

SUCH 

SUCH  THAT 
THAT 
THAT  IS 
BY 


Qualify  By  Attribute  Instance 

When  the  attribute  criterion  is  specified  as  attribute  name,  the 
condition  for  membership  in  the  new  set  is  independent  of  attribute  values. 
It  depends  only  on  an  instance  of  the  attribute  being  present  in  the  ASSM 
when  a positive  connector  is  used  and  absent  from  the  ASSM  when  a negative 
connector  is  used.  The  next  statements  are  valid  examples  of  this  type 
of  set  definition. 


SET  INTJ/AL  = DATA  WITH  INITIALJALUE. 
SET  NO  LOCALITY  = ALL  WITHOUT  LOCALITY. 
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Qualify  By  Attribute  Value 

The  second  form  of  the  attribute  criterion,  (i .e. , attribute-name 
[<relat1onal  operator>]  value)  allows  the  definition  of  the  new  set  to  be 
based  on  attribute  values.  When  a positive  connector  is  used  with  this 
form,  the  new  set  will  contain  members  of  the  subject  set  that  have  an 
attribute  value  which  satisfies  the  relational  operator.  The  use  of  a 
negative  connector  will  cause  the  new  set  to  contain  members  of  the  subject 
set  that  do  not  satisfy  the  relational  operator.  If  the  optional 
relational  operator  is  not  specified,  the  equal  sign  (i.e.,  test  for 
equality)  is  assumed.  A list  of  legal  relational  operators  is  provided  in 
the  following  table. 

Relation  Operator  Meaning 

> Greater  than 

>=  Greater  than  or  equal 

<>  Not  equal 

= Equal 

<=  Less  than  or  equal 

< Less  than 

The  value  that  is  specified  in  the  attribute  criterion  can  be  an 
integer  or  real  number,  a value  name,  or  a text  string  that  is  not  longer 
than  60  characters.  The  relational  operators  = and  <>  are  the  only  ones 
that  are  legal  if  the  value  is  specified  as  a text  string  or  as  a value 
name. 

The  next  group  of  statements  are  examples  of  the  definition  of  sets 

based  on  attribute  values. 

SET  INT_VAL_ZER0  = DATA  WITH  INITIAL JALUE  0. 

SET  INT_VAL_GT_ZER0  = DATA  WITH  INITIALJALUE  > 0. 

SET  GAMMA_DATA  = DATA  WITH  USE  = GAMMA. 

SET  MY_ALPHAS  = ALPHA  SUCH  THAT  ENTERED_BY  = "THIS  IS  MINE". 

6.1.4  Defining  Sets  By  Relationship  Qualification 

A set  can  be  defined  to  contain  elements  with  or  without  certain 
relationship  characteristics  with  the  qualify  by  relationship  statement. 

The  syntax  of  the  statement  is: 


if i er> 


SET  new-set-narne  = <set  identifier>  <posiJ1ve  connector> 

|<negative  connector^ 

[MULTIPLE]  relation-name  j relation-optional -wordj^ 
[<set  identifier>] . 


The  first  set  identifier  selects  a subject  set  of  candidate  members  that 
can  be  included  in  the  new  set.  The  legal  terms  that  can  be  used  for 
positive  connector  and  negative  connector  are  described  in  Section  6.1.3.  The 
MULTIPLE  option  is  used  to  indicate  that  an  element  in  the  subject  set  must 
have  more  than  one  instance  of  the  specified  relationship  before  it  can  be 
included  in  the  new  set.  The  relation  name  can  be  a primary  relation  or  a 
complementary  relation.  Any  number  of  RSL  relational  optional  words  may 
appear  after  the  relationship  to  increase  the  readability  of  the  statement. 

The  optional  object  set  (identified  by  the  second  set  identifier)  is  used  to 
indicate  that  an  element  in  the  subject  set  must  have  a relationship  instance 
with  one  or  more  of  the  elements  in  the  object  set  to  satisfy  the  qualifica- 
tion criterion.  If  the  object  set  is  not  specified,  an  element  in  the 
subject  set  is  qualified  for  inclusion  in  the  new  set  by  having  an  instance 
of  the  relationship  with  any  element  in  the  ASSM. 

The  following  examples  demonstrate  uses  of  the  qualify  by  relation- 
ship statement.  The  RADX  comment  that  appears  with  a statement  describes 
the  contents  of  the  set  being  defined. 

SET  USED_DATA  = DATA  THAT  IS  INPUT 

(*DATA  ELEMENTS  WHICH  HAVE  AN  INSTANCE  OF  THE  INPUT 
RELATIONSHIP.*). 

SET  NOT_USED_DATA  = DATA  THAT  IS  NOT  INPUT 

(*DATA  ELEMENTS  WITHOUT  AN  INSTANCE  OF  THE  INPUT 
RELATIONSHIP.*). 

SET  USED_BY_ALPHAJJPDATE_STATE  = DATA  THAT  IS  INPUT  TO  UPDATE_STATE 

(*DATA  ELEMENTS  THAT  ARE  INPUT  TO  UPDATE_STATE.*) . 

SET  ERROR J = DATA  THAT  IS  MULTIPLE  CONTAINED 

(*DATA  ELEMENTS  WITH  MORE  THAN  ONE  INSTANCE  OF  THE 
CONTAINED  RELATIONSHIP.*). 

SET  SIMPLE  = MESSAGE  THAT  IS  NOT  MULTIPLE  MADE  BY  FILE 

(♦MESSAGE  ELEMENTS  THAT  ARE  NOT  MADE  BY  MORE  THAN  ONE  FILE.*). 


6.1.5  Defining  Sets  By  Structure  Qualification 

Implicit  relationships  between  structures  and  elements  used  in 
structures  may  be  used  for  defining  a new  set  of  elements  that  have  or  do 
not  have  certain  structural  characteristics.  These  implicit  relationships 
are  named  REFERS  and  REFERRED.  They  cannot  be  explicitly  input  through  the 
RSL  translator  but  they  are  implicitly  defined  when  a structure  is  entered 
in  the  ASSM. 

The  REFERS  relationship  exists  between  an  element  with  a structure 
and  the  elements  used  on  the  structure.  The  REFERRED  relationship  is  the 
complement  of  the  REFERS  relationship.  These  implicit  relationships  are 
used  in  the  same  manner  as  RSL  relationships  are  used  to  define  a set  by 
relationship  qualification  as  explained  in  Section  6.1.4.  The  syntax  for 
using  REFERS  and  REFERRED  is: 


SET  new-set-™™  - <set  identifier* 

[MULTIPLE]  jrelational -optional-word^ 

[<set  identifier]. 

The  following  examples  illustrate  different  uses  of  this  statement. 

SET  R_NET_NO_STRUCTURE  = R_NET  WITHOUT  REFERS. 

SET  R_N ET_USI NG _U PDAT EJSTAT E = R_NET  WHICH  REFERS  TO  UPDATEJSTATE. 

SET  ALPHAS  JOT  JJSED  = ALPHA  THAT  IS  NOT  REFERRED. 

SET  ALL_N E ED F.D_B Y_R_N ET_RADAR_SUMMAR Y = ALL  THAT  IS  REFERRED  TO 
BY  RADARJSUMMARY. 

6.1.6  Defining  Hierarchies 

There  are  several  hierarchies  that  exist  in  the  definition  of  RSL 
such  as  data  hierarchies  and  structure  hierarchies  that  can  be  identified 
to  RADX  and  used  later  as  a "road  map"  to  trace  through  the  ASSM  for  the 
purpose  of  defining  a set  or  determining  the  order  to  extract  and  display 
information.  A RADX  hierarchy  is  defined  using  the  following  syntax: 
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| hierarchy-name  = ^<set  identifier  <binding  relation: 

joptional -wordj^  <set  identifier  j . 

In  the  statement,  hierarchy  name  is  a unique  name  that  will  be  used  to 
reference  the  hierarchy,  the  set  identifiers  designate  sets  that  must  be 
defined  before  the  hierarchy  is  defined,  and  binding  relation  is  any  RSL 
relation  or  an  implicit  relation,  REFERS  or  REFERRED. 

For  example,  the  following  graph  illustrates  an  RSL  information 
hierarchy  that  can  exist  in  the  requirements  data  base: 


Ihierarchy 

(HIER 


The  nodes  in  the  graph  represent  sets  (in  this  case  predefined  element 
type  sets)  and  the  branches  represent  binding  relationships  between  the 
sets.  This  hierarchy  can  be  named,  say  INF0_S0URCE,  and  input  to  RADX 
for  future  use  by  defining  the  connectivity  of  the  graph  (i.e.,  hierarchy) 
as  follows: 

HIER  INFOJSOURCE  = INPUTJNTERFACE  PASSES  MESSAGE; 

MESSAGE  MADE  BY  FILE; 

MESSAGE  MADE  BY  DATA; 

FILE  CONTAINS  DATA; 

DATA  INCLUDES  DATA. 
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When  this  command  is  input  to  RADX , it  is  translated  and  stored  for 
future  reference  by  other  RADX  commands.  In  addition  to  the  connectivity 
information  between  the  hierarchy  entries,  a top-of-the-hierarchy  is 
implicitly  defined  as  the  first  set  that  appears  in  the  hierarchy  descrip- 
tion. For  the  above  example  INPUTJNTERFACE  is  the  top-of-the-hierarchy. 
This  will  be  used  to  determine  the  starting  point  in  the  "road  map"  when  a 
trace  through  the  ASSM  is  made  following  the  hierarchy. 

Whenever  a trace  is  performed,  it  is  done  in  a depth-first  manner. 
For  the  example,  the  order  of  tracing  would  occur  as  follows: 

1)  from  INPUTJNTERFACE  to  MESSAGE  via  PASSES. 

2)  from  MESSAGE  to  FILE  via  MADE  BY. 

3)  from  FILE  to  DATA  via  CONTAINS. 

4)  from  DATA  to  DATA  via  INCLUDES  repeated  until  a point  is 
reached  where  the  set  of  DATA  does  not  INCLUDE  any  other 
DATA. 

5)  from  MESSAGE  to  DATA  via  MADE  BY  (a  return  back  up  the 
hierarchy  was  made  after  reaching  the  maximum  depth  in 
Step  4). 

6)  from  DATA  to  DATA  via  INCLUDES  repeated  until  the  trace 
is  exhausted  as  in  Step  4. 

The  user  is  cautioned  that  duplicate  entries  in  a hierarchy  defini- 
tion will  cause  duplicate  tracing  through  the  ASSM.  For  example,  suppose 
that  the  above  hierarchy  had  been  written  as: 

HIER  INF0_S0URCE  = INPUTJNTERFACE  PASSES  MESSAGE; 

MESSAGE  MADE  BY  FILE; 

FILE  CONTAINS  DATA; 

DATA  INCLUDES  DATA; 

MESSAGE  MADE  BY  DATA; 

DATA  INCLUDES  DATA. 

Since  here  are  two  entries  for  DATA  INCLUDES  DATA,  lines  4 and  6, 
many  duplicate  traces  would  occur.  For  example,  after  entry  3 traces  from 
FILE  to  DATA  via  CONTAINS,  entry  4 would  trace  from  DATA  to  DATA  via 
INCLUDES  and  later  entry  6 would  be  processed  causing  a duplication  of 
what  was  done  at  entry  4,  tracing  from  DATA  to  DATA  via  INCLUDES.  The 
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same  type  of  activity  would  occur  following  the  processing  of  entry  5 which 
is  a trace  from  MESSAGE  to  DATA  via  MADE  BY. 


/ 


6.1.7  Defining  Sets  By  Hierarchy  Qualification 

This  capability  is  used  to  define  a set  of  elements  as  those  which 
are  members  of  a given  set  and  are  reached  while  tracing  a hierarchy  as 
defined  in  Section  6.1.6.  The  syntax  of  this  define  set  statement  is: 


SET  new-set-name  = <set  identifier  <positive  connector 

i HIERARCHY^1  . . . 

IHIER  I ’11erarchy-name. 

The  set  identifier  selects  a set  which  contains  candidate  members  for 
inclusion  in  the  new  set,  the  positive  connector  Is  one  of  the  terms  defined  in 
Section  6.1.3,  and  hierarchy  name  is  the  name  of  a previously  defined 
hierarchy. 

For  an  element  to  become  a member  of  the  new  set,  it  must  satisfy  the 
following  criteria: 


1) 


it  must  be  a member  of  the  candidate  set 

it  must  be  encountered  while  traversing  the  hierarchy. 


[ 


Some  examples  of  how  a hierarchy  is  used  to  define  a set  are  given  next 
using  the  following  hierarchy  definition. 


SET  SOURCE JNTERFACE  = INPUT_INTERFACE. 

HIERARCHY  INFOJOURCE  = SOURCE  JNTERFACE  PASSES  MESSAGE; 

MESSAGE  MADE  BY  FILE; 

MESSAGE  MADE  BY  DATA; 

FILE  CONTAINS  DATA; 

DATA  INCLUDES  DATA. 

Notice  that  in  this  example  the  user  defined  SET:  SOURCEJNTERFACE  Is  the 
top-of-the-hierarchy.  It  is  required  that  the  set  be  defined  before  the 
hierarchy  is  defined  but  the  set  can  be  redefined  as  will  be  shown  in  one 
of  the  examples  that  follows. 

The  following  examples  will  describe  the  desired  contents  of  a set 
and  the  RADX  commands  that  can  be  used  to  accomplish  the  objective. 


6-15 


1 


Example  1 

OBJECTIVE:  A SET  X which  contains  all  the  INPUTJNTERFACEs  in  the 

ASSM,  the  MESSAGES  that  PASS  them,  all  the  FILES  and  DATA 
that  MAKE  the  MESSAGES,  and  all  the  DATA  that  is  CONTAINED 
in  the  FILEs. 

COMMAND : 

SET  X = ALL  IN  HIER  INFO_SOURCE. 

Example  2 

OBJECTIVE:  A SET  Y consisting  of  the  INPUT INTERFACE:  RADARJN,  the 

MESSAGES  that  PASS  RADARJN,  the  FILEs  and  DATA  that  MAKE 
the  MESSAGES,  and  the  DATA  that  is  CONTAINED  in  the  FILEs. 

COMMANDS: 

SET  SOURCEJNTERFACE  = RADARJN. 

SET  Y = ALL  IN  HIER  INFO_SOURCE. 

Example  3 

OBJECTIVE:  Same  as  Example  2. 

COMMANDS: 

SET  SOURCEJNTERFACE  = INPUT JNTERFACE. 

SET  RADAR JRACE  = RADARJN,  MESSAGE,  FILE,  DATA. 

SET  Y = RADAR  JRACE  FROM  HIERARCHY  INFOJSOURCE. 

Example  4 

OBJECTIVE:  A SET  Z that  contains  only  the  DATA  which  is  a part  of  the 
INPUT  JNTERFACE  because  it  MAKES  a MESSAGE  or  is  CONTAINED 
in  a FILE  that  MAKES  a MESSAGE  which  PASSES  the  INPUT 
INTERFACE. 

COMMANDS: 

SET  SOURCEJNTERFACE  = INPUTJNTERFACE. 

SET  SOURCE  JRACE  = INPUTJNTERFACE  OR  DATA. 

SET  TEMP  = SOURCE  JRACE  IN  HIER  INFO_SOURCE. 

SET  Z = SET  TEMP  MINUS  INPUTJNTERFACE. 

NOTE:  When  SET  TEMP  was  defined  it  contained  only  element  types  INPUT_ 
INTERFACE  and  DATA.  The  set  did  not  contain  any  MESSAGES  or  FILEs 
because  they  were  not  in  SET:  SOURCE  TRACE  which  was  the  original  set 
being  qualified.  With  the  removal  o T INPUTJNTERFACEs  from  SET  TEMP, 
the  objective  is  satisfied  for  SET  Z.  The  reason  that  INPUTJNTERFACE 
needs  to  be  in  SOURCEJRACE  is  to  satisfy  the  requirement  that  the 
candidate  set  being  qualified  must  contain  the  starting  points  for  the 
trace. 

6-16 

I 


6.1.8  Using  Sets  to  Analyze  a Requirements  Data  Base 


One  of  the  primary  purposes  for  the  set  definition  facility  of  RADX 
is  to  provide  a technique  that  allows  a user  to  analyze  a requirements  data 
base.  Table  6.1  contains  RADX  commands  that  can  be  used  to  analyze  a data 
base  for  compliance  with  the  RSL  conventions  described  in  Section  3.0.  The 
commands  are  grouped  according  to  the  area  of  the  requirements  specifica- 
tions that  they  analyze.  Those  sets  which  have  a comment  identify  a viola- 
tion of  a convention  if  they  are  not  empty.  The  comment  describes  the 
violated  convention.  The  sets  without  a comment  are  used  in  a temporary 

manner  for  building  the  sets  that  identify  errors.  The  table  also  includes 

♦ 

the  hierarchy  definitions  that  are  required  to  form  the  sets. 

The  LIST  command  that  is  described  in  Section  6.2  can  be  used  to 
display  the  contents  of  the  sets  which  identify  errors  in  order  to  document 
the  anomalies  that  are  present  in  an  ASSM. 


t., 


Table  6.1  Examples  of  RADX  Conriands  For  Requirements  Analysis 


COMMANDS  TO  TEST  SUBSYSTEM  AND  INTERFACE  SPECIFICATIONS 


SFT  IJNCONNECTFD.SURiYSTEM  = SUBSYSTEM  THAT  IS  NOT  CONNE C l F. D 

(*  ALL  SUBSYSTEMS  MUST  bE  COMNECTtD.  *). 

SET  INTERFACE  = INRUT.INTERF ACE  OH  0 JTPuT.  I NTE  RE  ACE  . 

SET  iNTEPFACE.NOr.CONNECTtO  = INTERFACE  wIT-tOuT  CONNECTS 

(*  AN  INTERFACE  MUST  CONNECT  TO  A SUBSYSTEM.  *), 

SFT  TOO_many_CON'JECTS  = INTERFACE  That  MULTIPLE  CONNECTS 

<«  AN  INTERFACE  CANNOT  CONNECT  TO  more  Than 
one  subsystem.  *>. 

SFT  T NTFHK ACE_.NO _MESS AGE  = INTERFACE  WITHOUT  HASSES 

(o  AN  INTERFACE  MUST  PASS  AT  LEAST  ONE  MESSAGE.  •). 
SET  ouT.mSG  = MESSAGE  THAT  PASSED  OU TPUT_I N 1 EH  - ACE . 

SET  DUT_mSG_NOT_£'0PM£O  = OUT.mSg  THAT  IS  NOT  FOR>*EO 

(*  ALL  MESSAGES  That  HASS  AN  OUTPUT_INTEhF ACE 
MUST  BE  FORMED.  *>  . 

SET  MS3_N0T_PASS-:0  = MESSA&t  THAT  IS  NUT  PASSED 

<*  A MESSAGE  MUST  HE  PASSED  HY  EITHER  AN  INPUT 
OR  OUTPUT  INTERFACE.  *). 

SET  mULTI_paSSEO_MESSAGE  = mEsSAGE  ThaT  IS  MULTIPLE  PASSED 

<»  A MEsSAGr.  CAN  ONLY  3aSS  ONE  INTER E®Ct . *). 

SFT  MULTI_JSE!)_IN:>UT_INE  = I NPU  T_I  NTERF  ACE  ThAT  IS  MULTIPLE  lEFtHHEO 

7*  an  input_7ntfrface  cannot  he  referenced 

BY  MORE  THAN  ONE  R_NET . *). 


COMMANDS  TO  TEST  STRUCTURE  SPECIFICATIONS 


SET  UNENAPLEri_H_NETS  = R _N  E T IhaT  IS  NUT  ENABLED 

<«  R_NETS  MUST  HE  ENAH.slD,  » ) . 

SET  ot'r.JNPUT.lN-  = R_NET  THAI  REFERS  TO  I N JUT  _1  NTERF  ACE . 

SET  Ml SSING_InF_- NAHLE  = REE _1 NPUT_I NF  1HA1  IS  NOT  KNAHLED 

BY  INPUT.IMTERFACi 

(*  AN  R.Nt T THAT  REFERENCES  AN  I NPUT _I N TERE ACE 
MJST  Ht  ENAHLEU  HY  T Ht  INTERFACE.  *>. 

SET  HAD_MULT I_EN«RLE  = REF _I NPUT_1 NF  THAT  IS  mjlTIPLE  EnAHLED 

(*  AN  R.NE  f WHICH  REFERENCES  AN 

I NPU?_i NT  ERF ACE  CAN  ONLY  HE  ENAHLED 
HY  TnE  INTERFACE.  »>. 

SFT  NOT_Rtr_lNPUT_INF  = R_NE  T MINUS  RtF_IN3UT_lNF • 

SFT  HAD_INTFRF  ACr_tNAHLf.Mf  NT  = NOT_REF_INPUI_InF  That  IS 

ENABLED  BY  INPUT.INTER- ACE 
<o  AN  R_Nt  T SHOULD  NOT  dF  ENABLE  D BY  AN 
I N°U1  _I  -N  T ERE  A CE  UNLESS  The  INTERFACE 
APPERAs  IN  THE  R_NE  T STRuCIUkF.  «). 

SET  STRUCT UHE_NODES  = alpha.  SUBNET.  EVENT.  V A _ I n A T I On.PU l N T , 

INPUT.InTEREACE,  OUT  PUT  .INTERFACE  . 

SFT  VETS  = R_mET  OR  SUBNET. 

SFT  IINUSf D.NOOES  = STRUCTURE .NODES  SUCH  That  NDT  REFERRED  TO  HY  NETS 

(o  E Op  The  REOUIREMENIS  TO  HE  COMRIETEm  alL 
ALPHA,  SUBNET.  EVEN],  VALID AT10N.H0INT . 

1 nput .interface * and  dutpht.intereacf 

ELEMENTS  MUST  Ht  USED  IN  EITHER  Am  R.NtT 
Oi  SUBNET  STRUCTURE.  * ) . 


. 


! 
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Table  6.1  Examples  of  RADX  Commands  For  Requirements  Analysis  (Continued) 


COMMANDS  TO  TEST  INFORMATION  MEMBERSHIP  SPECIFICATIONS  (CONTINUED) 

SFT  mSG.INFO  = a.l  IN  HIe.P  mE->SAGE_TRaCF  . 

SET  mS3_InFO  - mSG_InFO  minus  MESSAGE. 

SFJ  FNt7tY_ANO_m>oIiMFO  = ENTITY_lNFO  A NO  wSG_lNFO 

(«  A SINGLE  OATA  0»  FI_E  CANNOT  BOTH  MAk£ 

A MESSAGE  AND  HE  ASSOCIATED  *ITH  AN  ENTITY.  *). 

SET  “S3_FIlE:_INF0  = M3G_lNFO  «ND  FILE.IUFO 

<*  A DATA  item  cannot  301H  MAKE  A MESSAGE 
AND  HE  CONTAINED  IN  A FILE.  *). 

SFT  CLASS_NO_TYPE  = ENTITY_CL4Sb  WITHOUT  COMPOSED  ENTITY_TYt>t 

(«  AN  ENT  1 T Y_CL ASS  MUST  HI  COMPOSED  OF  «T 
LEAST  ONE  ENTITY_TYP>.  »). 

SFT  TYPF_ND_CLASS  = FNTITY_TYPF  WITH  NO  COMPOSES 

(«  AN  FNT1TY_TYPE  MUST  COMPOSE  AN  ENT  I T Y _CL ASS.  *). 

SET  MULT T.COMPOSES  = FNT I TY_TYPt  THAT  MULTI=LE  CUMPOStS 

(*  AN  EM  T 1 TY_T YP£  CANNOI  COMPOSE  MOHE  THAN 
ONE  ENT  I T Y_CL  ASS . *) . 

SFT  mulTI_OHDEPE 0 = FILE  THAT  IS  MULTIPLE  ORDERED 

(*  A FILE  CANNOT  HE  ORDERED  HY  MOHE  THAN  ONE 
DATA  ELEMENT.  °). 

SET  nPDFP I NG_D  AT  A = DATA  THAT  OPDEHS  FILE. 

SET  nEEOS_TO_hE_TN_E  ILE  = OPDr.H  1 NG_DA  T A THAI  IS  NOT  CONTAINED 

(*  A DATA  ELEMENT  THAT  OHOEhS  A FILE  MUST 
HE  CUN  T A I NE  D IN  THE  flLE.  * ) . 

SET  BA  0_ORDF  R I NG  _f*A  T A = OPDt  R I mg_D  AT  A Tha  T INCLUDES 

(*  ONLY  LOWEST  LEVEL  DAlA  CAN  ORDER  A FILE.  *). 

SCT  EMPT Y_F ILF  = FILE  WITHOUT  CONTAINS 

{*  A FILE  MUST  CONTAIN  AT  .EAST  ONE  DATA  ITEM.  *). 

SFT  FMPTY_Mt:SSAGE  = MESSAGE  THAT  IS  NOT  MADE 

(«  A MESSAGE  MUST  BE  MADE  3 Y EITHER  DATA  OR 
FILE  ELEMENTS.  *) . 

SFT  FMPTY_FNTITY_TYPE  = E NT  I T Y_T  YPE  WITHOUT  ASSOCIATES 

<*  AN  ENTITY_TYPE  MUST  ASSOCIATE  AT  LEAST  ONt 
OATa  Oh  t-  ILE  ELEmENI  . *)  . 

COMMANDS  TO  TEST  INFORMATION  USAGE  AND  ASSIGNMENT  SPECIFICATIONS 


H I E H SUE S YS _ TO _U A T A = SUHSYSTI M CONNECTED  I NPU T _I NT E RF ACE , 

INPUT.lNTtHF ACE  HASSES  MESSAGE* 

MESSAGE  MADE  BY  FILE. 

MESSAGE  MADt  BY  OATA. 

FILE  CONTAINS  OATA, 

OATA  INCLUDES  OATA. 

H I ch  1>ATA_T0_SJHSYS  = SIHSYSTtM  CONNECTED  J JTP J T_ l NT ERFACE . 

OUTPUT.INTFHFACF  PASSES  MESSAGE. 

MESSAGE  Made  HY  FILE. 

MESSAGE  M«Ot  MY  D A f A . 

FILE  CONTAINS  DATA, 

DATA  INCLUDES  DATA. 

HTER  ALPHA  _IN  = ALPHA  INPUTS  FILE. 

alpha  I NPuTS  Data, 

FILE  CONTAINS  OATA 
OATA  INCLUDES  U A T A . 


BEST  AVAILABLE  COPT 
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Table  6.1  Examples  of  RADX  Commands  For  Requirements  Analysis  (Continued) 


COMMANDS  TO  TEST  INFORMATION  USAGE  AND  ASSIGNMENT  SPECIFICATIONS  (CONTINUED) 


HTTP  VR_TN  = VAlTOATIOn_=-OInT  RECORDS  FILE. 

valija r ion.point  records  data, 

FILE  CONTAINS  OATA, 

oata  includes  data. 

HIFR  ALPnA_0'JT  r ALPHA  OUTPUTS  FILE. 

ALPHA  OUTPUTS  DATA, 

FILE  CONTAINS  OATA, 

OATA  INCLUDES  DATA. 

SFT  tT uNOAVO_DAT A = FOUND,  RECOkU_FOUND , C_JCK_TTME. 

SET  SPFCIFItn_OAT A = nATA  MINUS  ST  AND AkD_0 A I A . 

S^T  so JPCE _1  = ALL  In  hIER  SUas YS_TO_OAT A . 

SFT  SOJHCF_?  = ALL  IN  HIr.R  aLPhA_OUT. 

SFT  SO J^CE  _3  = DATA  WITH  1 NI T 1 AL.VALUE . 
spt  sojHres  = source _i.  sojwct_?.  snunce_3. 

SET  SOJPCES  = SOJPCeS  AN)  SPEC  1 F IED_DA T A . 

SET  N0_S()JJCE  = spec  i f IED_f)A  T A «1NUS  SOURCES. 

SET  STNK_i  = ALL  IN  HIE*  DAIA_TO_SUPSYS. 

SF  T S1NK_P  = ALL  IN  HIE*  ALPHA_IN. 

SFT  slvK_3  = ALL  IN  hjfh  VP_IN. 

SFT  SlNK_4  = oata  TrAT  IS  HtFExHED. 

SFT  SINK_S  = OATA  WHICH  DELAYS  EVENT. 

SFT  SI\|K_6  = OATS  «hICH  ORDERS  FILE. 

SFT  SINKS  = SINK_1.  SJNK_?,  S l NK_3 , S1NK_A,-  SI  NK_E>,  SlNK_h. 

SET  SINKS  = SINKS  AND  SPECIF  1 1 0_DAT  A . 

SFT  mO_SIN<  r SPrClF ien_DATA  MINUS  SINKS. 

SFT  DATA  _N3_SO JhCE  _ANO_S INK  = NO_SOU*CE  AND  NO_SfNK 

(*  A DATA  ITEM  SHOULD  HAVE  A SOURCE  AND 
A SINK.  *). 

SFT  OATA_WITH_S0 IHCE_RUT_NO_SInK  = SOURCES  MTNJS  SINKS 

(*  IF  A DATA  ITFM  HAS  A SINK.  ThFN  IT  MUST 
HAVE  A SINK.  *>  . 

SET  OATA_WIIH_SI'IK_HUT_N0_S0Ur<Ct  = SINKS  MINUS  SOUHCES 

f«  IF  A DATA  ITFM  HAS  A SINK.  THEN  IT  MUST  HAVE 
A SOURCE.  »). 


COWANDS  TO  TEST  ENTITY  OPERATION  SPECIFICATIONS 


SFT  CLASS_\OT_CREATEO  = CNTITY_CLASS  THAT  IS  ND7  CREATED 

(«►  ALL  t N I It  Y_CL  A SSF.S  MJST  bFI  CREATED.  *>. 

sft  rLASs_NOT_DEsrpr.YEn  = entity _cl ass  that  is  not  destroyed 

(A  The  analyst  should  REVIEW  THF  reason  why 
An  ENTITY.CLASS  IS  NJT  DESIROYED.  *) . 

SFT  TY3P_N0T_SET  = FNTlTY_TYPt-  THAT  IS  NOT  a*  T 

<*  EVERY  tN I 1 TY_TYPfc  MJST  3E  SET.  •). 

SFT  TY=>F  _NOT_RFprwtr  CFO  = E*1'  T I T Y_T  YPE  THAT  IS  NOT  RE^ERR^D. 

SFT  rl  aSS_Of”uN“E'EPofd  = FNTITY.CLASS  SUCH  THAT  COMPOSED 

OF  T YPF._NOT_RFFE  RE  NT  ED  . 

SET  rLASS_NOT_*ErERPEO  = CL ASs_UF _UNRE FF RKE D THAT  IS  NOT  RFFERPED 

(«  Each  En7iTY_CLASS  MjaT  St  DIRECTLY  USED  ON 
A STRUCTURE  OH  INDIRECTLY  USt  D HF.CAUSt'  An 
ENT  I T V_T YPE  WHICH  CDMPOStS  THE  CLASS  IS 
USED.  «). 
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BEST  AVAILABLE  COPY 


Table  6.1 


COPI 


BEST 

Examples  of  RADX  Comnands  For  Requirements  Analysis  (Continued) 


COMMANDS  TO  TEST  INFORMATION  LOCALITY  SPECIFICATIONS 


HIFRaRC~Y  FIL?_Ti'Cr.  = FILE  CONTAIN?  DATA; 

data  includes  data. 

HIERARCHY  wESSAGi_TBACF  = MESSAGE  MADE  my  r 1 LE  * 

MESSAGE  MADE  BY  DATA; 

nATA  includes  data. 

HIERARCHY  tNT  I T Y _TBACF  = E.nT  I I Y_CLASS  ASSOCIATES  FILE; 

FILE  CONTAINS  data; 
data  iNCLJUtS  data; 

FMT I TY_CL ASS  ASSOCIATES  DATA; 

ENTITY_CLpSS  COMPOSED  OF  E NT  I TY_T YPt ; 

FNTITY.TYME  ASSOCIATES  FILE; 

FNT I T Y_T  YMF  ASSOCIATES  DATA. 

SET  ff'TTTY_mEm^e->s  = ftLL  In  HIERARCHY  EnTI TY_TRAC£. 

SET  LOCAL_ENTITY_MtM-»EWS  = F NT  I T Y_ME  MHEhS  *ITH  LOCALITY  LOCAL 

(»  THE  LOCALITY  OF  ALL  ENTITY  RELATED  INFORMATION 
MUST  Be  GLOBAL.  *>. 

SET  mF$SAG£_mFM3- Bi  _ 4LL  jN  -iIeoaRCHY  MESSAGE  _T  MACE. 

SET  Gi  ORAL.MESSA-E.MEMMF.fS  = MESS AGF _mEMHE r S WITH  LOCALITY  GLOBAL 

<*  THE  LOCALITY  OF  ALL  MESSAGE  BELATED  INFORMATION 
MJST  Be  LOCAL.  *). 

SET  FILFS_NOT_lN_MESSAGE  = FILE  WITHOUT  ma<£S. 

SET  EILES_NOT_lN_tNT ITY  = ElLt  THaT  IS  NOT  ASSOCIATED. 

SET  IN  )*-'R£Nr>FNT,FTLL  = F IL£S_MlT_IN_MESSA3i»  AND  FILES  _NO  r_lN_t~NTlTY. 
SET  F.Ln_Of  FAULT  IlF  = i Nl>EPENf)t'NT_F  ILE  WITHOUT  LOCALITY. 

SFT  '=La_SRcCIFIFO_FILE  = I NOE^E  NOENT  _E  I LE  *I1H  LOCALITY  = GLOBAL. 

SET  GL0*AL_F1LE  = Gl B_OEEAULT_EIlE  OS  GLB_SyEC I F I EU_E I LE . 

SFT  I.OCAL.FILE  = IN0EREN0ENT_HLE  MINUS  GLOBAL  _F  ILE. 

SFT  GLB_F  ILE_TSACE  = OATA  0-  GLOhAL_FILE. 

SFT  I OC _r I LE _T S a Ct  = OATA  OR  LOCAL.FILE. 

SFT  r.LOMAL_FILE_MEMBFWS  = GLH_F I LE_T R ACE  IN  HIER  FILE.TRACE. 

SET  LOCAL _OATA_IN_GLOBAL_FILE  = GLOP AL_F IL i _«E Mrit RS  WITH 

LOCALITY  = LOCAL 

(«  THF  LOCALITY  OF  THE  MEMBERS  OF  A GLOBAL 
FILE  MUST  NOT  BE  LOCAL.  *). 

SET  LOC.-l_FILE_Mr'V*  PS  = LOO_HLE_TPA CE  IN  RIER  FILF.TBALF. 

SFT  G|.0°AL_OATA_IN_LOCAL_FILE  = LOCAl_FILE_mFMSepS  WITH 

LOCALITY  = GLOBAL 

<*  THE  LOCALITY  OF  THE  MEMBERS  OF  A LOCAL 
FILE  MUST  NOT  HE  GLOBAL.  * ) . 


COMMANDS  TO  TEST  DATA  TYPE  AND  USE  SPECIFICATIONS 


SFT  FNJ"  = DATA  «ITH  TYPE  ENUMERATION. 

SET  «T  SSING_panG-‘  = FNIJM  WITH  NO  RANGE 

<«  A DATA  WITH  TYPE  END ME  BAT  I UN  MUST  HA  VF  AN 
INSTANCE  OF  THE  BANG-  ATTRIBUTE.  •>. 

SET  RN5  = DATA  WITH  RANGE. 

SFT  M()_rvPE  = RN".  *ITH  NO  TYPf  . 

SET  RPOm;_TYPF  = RNG  WITH  TYPE  <>  ENUMERATION. 

SET  OAT«_NEEOlNG_TYPF_ENJMEBA r ION  = »bONT_ITBE  0*  NO  _t  YPr 

(*  ALL  DATA  WITH  4 B A N 3 e ATTRIBUTE  MUST  H/vVE 
A TYPE  ANO  THE  TYPE  MUST  Rt  ENUMERATION.  •). 
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Table  6.1  Examples  of  RADX  Commands  For  Requirements  Analysis  (Continued) 


COMMANDS  TO  TEST  DATA  TYPE  AND  USE  SPECIFICATIONS  (CONTINUED) 

I 0 w ► S T _0  A T A r DATA  WITHOUT  I MCLUDtS  DATA. 
mISSING.TYPE  = L OwF S T _0  AT  A N I T H n j T TYPE 

(*  ALL  REmU I REmF  NTS  LEVEL  DATA  MUST  HAVE  A 
SPECIE IFD  TYPE.  *) . 

GAMMA_OATA  = OAT  A WITH  USE  = GAMMA . 

RPTHDAT*  = OA  f A WITH  USE  = BOTH. 

OAMMA_DAT  A = G4MM A_0  A T A OH  BUTH_DATA. 

incop«ect_gamma_oata  = gamma_oata  that  includes  data 

(*  DATA  WITH  USF  GAMMA  CANNOT  INCLUuE  OTHER 
•DATA.  *>. 

MISSING _USE_ATTRTBUT£  = LOWFST_0 AT  A WITHOUT  USE 

(*  ALL  LOWEST  LEVEL  DATA  SHOULD  HAVE  USE  = GAMMA 
OH  USE  =HOTH.  *>. 

TNCfTRPECT_BETA_DATA  = LOWES  T_DAT A WITH  JSE  RPTA 

<*  LOWEST  LEVEL  DATA  CANNOT  HAVE  USF.  BETA.  *). 


COMMANDS  TO  TEST  ORIGINATING  REQUIREMENTS  AND  VALIDATION  SPECIFICATIONS 


SF.T  pED'UHEMFnTS  = OPIG1 NA T I NG.REGUI REMENT  ,DR  DECISION. 

SFT  NOT.OECOMPOSED  = REOUI REMt  NTS  WITH  NO  TRACES 

(«  ALL  ORIGINATING .REQUIREMENTS  ANO  DECISIONS 
MUST  HE  DECOMPOSFO  aT  THnClNG  TO  UTHE  H 
ELEMENTS  FOP  THE  REQUIREMENTS  TO  he 
COMPLETE.  *). 

SFT  NnN_CONSTPAINlNG_PER_REO  = PERFORMANCE .REQUIREMENT  WITHOUT 

CONSTRAINS  VALIDATION.PATH 
(*  A PEPFORMANCE_REOUI RtMENT  MUST  CONSTRAIN 
A VAl.IOATI  ON_P  A TH  . »>. 

SET  TNCOmPlFTE_p- R_KEO  = PERFORM ANCE.REQU I RiMK N T WITHOUT  TEST 

<o  FOR  A PERFORMANCE  REQUIREMENT  TO  TO  BE 
COMPLETE  IT  MUST  HAVE  A TEST.  *). 

SFT  NETS  = R_nET  OH  SUHNET. 

SFT  l|NUSED_VAL_PT  = V AL I DA T I ON_PO INT  WHICH  IS  NOT  REFERRED  TO 

BY  VALI0AT70N_PATH 

(*  A VALID ATION_POlNT  MUST  HE  USED  HY  AT 
LEAS  I One  VAl.IOAT  IOn_PAIH.  *). 

SFT  MULTT_PPORlNO_vAL_POINTS  = VALIOATION.HOINT  THAT  IS  MULTIPLE 

REFERRED  TO  HY  NETS 

<*  A VAl.  I D AT  I ON_pOlNT  CAN  DNI.Y  OCCUR  ONCE 
IN  A NET  STRUCTURE.  »> . 
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6.2  LISTING  REQUIREMENTS 


This  section  describes  the  various  ways  that  RADX  can  be  used  to 
produce  requirements  documentation.  The  disposition  of  the  output  produced 
by  RADX  is  determined  by  the  following: 


1)  If  a LIST  command  is  Input  by  the  user,  then  the  output  from 
the  statement  is  routed  to  the  printer,  ANAGRAPH,  or  both  as 
specified  by  the  control  selected  via  REVS  EXECUTIVE  RCL 
(See  Section  4). 

2)  If  a PUNCH  command  is  used,  the  printed  output  from  the 
command  is  the  same  as  that  produced  using  the  LIST  command, 
and  additionally,  punched  cards  are  generated  that  contain 
all  printed  images  except  blank  lines  and  RADX  error  messages. 
The  actual  disposition  of  the  punched  cards  is  determined  by 

a parameter  of  the  REVSXQT  macro  as  described  In  Section  9. 

3)  If  a PLOT  command  is  used,  the  command  produces  graphic  dis- 
plays on  the  CALCOMP  plotter  of  the  STRUCTURES  of  those 
elements  being  plotted. 

The  examples  in  this  section  will  rely  mostly  on  the  LIST  command  to 
Illustrate  the  use  of  RADX  to  produce  documentation,  but  the  user  is  reminded 
that  the  keywords  LIST  and  PUNCH  can  be  interchanged  to  vary  the  disposition 
of  the  documentation. 

6.2.1  Listing  Sets 

All  LIST  operations  use  one  set  as  their  operand.  The  simple  syntax 
of  the  command  is: 

I LIST  l1 


[ PUNCH  fj 


<set  identifiers. 


The  set  Identifier  may  designate  any  set  that  is  defined  prior  to  the  use 
of  the  LIST  statement.  As  shown  in  the  following  examples,  set  identifier 
can  designate  the  universal  set  ALL  or  ANY,  an  element  type  set,  an  element  set, 
or  a user  defined  set. 

LIST  ALL. 

LIST  DATA. 

LIST  UPDATE_STATE. 

LIST  SET  X. 
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L 


When  a set  is  LISTed  the  members  are  displayed  alphabetically  by 
element  type  and  within  each  element  type  by  element  name.  After  each 
element  is  displayed,  associated  attributes,  relationships,  and  structures 
are  displayed.  Should  the  user  want  to  vary  or  eliminate  the  associated 
information  displayed  about  an  element,  the  APPEND  statement,  described  in 
Section  6.2.2,  may  be  used. 

The  requirements  information  produced  using  this  LIST  command  is  in 
an  indented  format  that  contains  legal  RSL  syntax.  An  example  output  is 
presented  in  Figure  6-1. 

6.2.2  Selecting  Associated  Information  to  be  Displayed 

The  APPEND  command  is  used  to  specify  the  associated  attributes, 
relationships,  and  structures  that  should  be  displayed  following  the  display 
of  an  element.  The  syntax  of  the  statement  is: 


APPEND  <type  identifier:*  -|<append  item>j>  . 


In  the  statement,  type  identifier  is  an  RSL  element  type  name,  the 
keyword  ANY,  or  the  keyword  ALL  and  indicates  the  element  type  or 
element  types  to  which  the  append  item  list  applies.  When  ALL  or  ANY  is 
specified,  the  list  is  applied  to  all  element  types  in  the  ASSM.  The 
following  is  a list  of  legal  append  items  and  the  information  that  it 
causes  to  be  appended  to  an  element  that  is  a subset  of  type  identifier. 

relation-name  - a particular  RSL  relationship. 

attribute-name  - a particular  RSL  attribute. 


REFERS 


REFERRED 


STRUCTURE 


- elements  that  appear  on  the  structure  of  the 
subject  element. 

- elements  with  structures  that  use  the  subject 
element. 

- all  attributes  in  alphabetical  order,  followed 
by  all  primary  relationships  in  alphabetical 
order,  followed  by  REFERS,  followed  alphabetically 
by  all  complementary  relationships,  followed  by 
REFERRED,  and  finally  the  element  STRUCTURE  or 
PATH. 

- no  associated  information. 

- R NET,  SUBNET,  or  VALIDATION  PATH  structure. 
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tRADX  COMMANDS 
LIST  DATA, 


DATAi  ACCEPTANCE. THRESHOLD, 

LOCAL  I T V * LOCAL. 

TYPE  I REAL, 

USE  t Gamma, 
included  in: 

DATA:  T1.T2.GATE.QATA 

DATA:  T3.GATE.PATA, 

DATA:  ACCOUNTEP.POR, 

initial. value i neither, 

LOCAl  I T Y | GLOBAL, 

RANGE  » "NE ITHER»COUNTED, SUMMED", 
TYPEI  ENUMERATION, 

USE:  BOTH, 

ASSOCIATED  WITH: 

entity.typei  lost.pulse 
entity.types  returned_pui.se, 
output  from: 

alpha:  set.counted 
alpha:  set. summed , 
referred  by: 

subnet:  sijm.retupnS 
subnet:  t allt.retuRns, 

data:  alph a.error , 

LOCAL ITYl  LOCAL, 

type:  peal, 
use:  gamma, 
included  in: 

DATA:  T1_T2.RECEIvE 

DATAI  T 3.RECE I VE , 

data:  alpha. phase. taper, 

LOCALITY:  LOCAL, 

type:  real, 

USE:  gamma, 
included  in: 

data:  t i.t2. transmit 

DATA:  T3.TRANSMIT, 


Figure  6-1  Sample  Output  From  Standard  LIST  SET  Command 


6-27 


ATTRIBUTE 


RELATION  ) 
RELATIONSHIP f 


PRIMARY 

COMPLEMENTARY 


- all  attributes  in  alphabetical  order. 

- all  primary  relationships  in  alphaoetlcal  order 
followed  by  all  complementary  relationships  in 
alphabetical  order. 

- all  primary  relationships  in  alphabetical  order. 

- all  complementary  relationships  in  alphabetical 
order. 


When  RADX  is  Initially  activated  the  append  item  for  all  elements  is 
initialized  to  ALL.  If  a new  APPEND  statement  is  entered  for  a type  identifier, 
the  append  item  list  replaces  the  previous  list  for  the  type  identifier  and 
remains  active  until  a new  APPEND  statement  changes  the  selection  or  RADX  is 
terminated . 

The  order  that  append  items  appear  in  the  APPEND  statement  determines 
the  order  that  associated  information  is  displayed  about  an  element.  A 
duplicate  item  in  the  statement  will  cause  duplicate  information  to  be 
displayed  for  the  elements  of  the  type  indicated  by  the  type  identifier. 

Examples  of  the  use  of  the  APPEND  statement  and  the  results  produced 
using  it  with  the  LIST  statement  are  provided  in  Figure  6-2. 

6.2.3  Listing  By  Hierarchies 

The  LIST  by  HIERARCHY  command  provides  a technique  to  vary  the  format 
and  order  of  the  display  of  stc  members.  The  syntax  of  the  command  Is: 

(list  ^ (hier  I1 

\ PUNCH ^ <set  identifier  positive  connector  }HIERARCHYJ 

(MAP  P 

hierarchy- name  <positive  connector*  SEQUENCE/  . 

( GROUP  ) 1 

In  the  statement,  positive  connector  can  be  any  of  the  terms  described 
m Section  6.1.3.  The  hierarchy  name  identifies  a hierarchy  that  must  be 
■ • ed  using  the  define  hierarchy  capability  described  In  Section  6.1.6. 

'►»  v*'  identifier  specifies  the  subject  set  from  which  elements  can  be 
» m ■ to  be  displayed.  The  optional  part  of  the  statement  is  called 
-•  ■ ,\»  i '.play  option.  If  one  of  the  options  is  not  explicitly  selected, 

•-  »on  Is  used  to  make  the  display.  Each  of  the 
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tRADX  COMMAND^ 

APPEND  FILE  | CONTAINS. 


(RAOX  COMMANDS 

LIST  FILE. 

filei  candidate 

f 

CONTAINS! 

DATA! 

CANDIDATE-ENERGY 

DATA! 

CANDIDATE-IMAGE-ID 

DATA! 

CANDIDATE-WAVEFORM 

DATA| 

priority, 

filei  command, 

CONTAINS! 

DATA! 

COMMAND-ENERGY 

DATA| 

COMMAND_IMAgE_IP 

DATA! 

COMMAND-WAVEFORM 

DATA! 

START-TIME, 

FILE!  STATE-FILE, 

CONTAINS! 

DATA| 

STATE-DATA 

DATA! 

STATE-ID, 

FILE  I TERMINATOR. 

CONTAINS* 

DATA|  DROP.REASON 
DATA!  DROP-TIME, 

FILE!  T1-T2-DATA, 

CONTAINS! 

DATA | Ti.T2.REC0RD. 
FILE!  Tl_ T2— GATE, 


CONTAINS! 

DATA! 

— w 

Tl— T2-GATE— DATA, 

FILE!  T 1—T2— WINDOW , 

CONTAINS! 

DATA!  TI-T2-WIND0W-0ATA, 

FILE!  TJ-OATA, 
CONTAINS! 
DATA| 

TJ-RECORD, 

FILE!  TJ-GATE, 
CONTAINS! 
DATA! 

T3— GATE -DATA , 

Figure  6-2  Sample  Use 

of  APPEND  and  LIST  Cotimands 
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( R A D X COMMAND* 

APPEND  R-NET*  STRUCTURE* 


(RADX  command* 
LIST  R-NET, 


R-NET*  CC-RESPONSE, 

STRUCTUREl 

INPUT.INTERFACEI  CC-IN 
ALPHA*  VALIDATE.HEAdER 
DO 

ALPHA*  ACKNOWLEDGE 
OUTPUT-INTERFACE*  CC.OUf 

AND 

CONSIDER  DATA!  COMMAND-ID 
IF  (HANDOVER-IMAGE) 

ALPHA*  TRACK.INITIATE 
VALIDATI ON— PO InT | C2— IMAGE— HANDOVER 

EVENT*  ALLOCATE 
OUTPUT-INTERFACE*  DaTA-RECORD 
OR  CINITIATE..ENGAGEMENT.MODE) 

ALPHA*  STARTER 

validation-point*  starting-point 

ALPHA*  ENGAGEMENT-INITIATION 
EVENT*  SCHEDULE 
EVENT*  SUMMARIZE 
TERMINATE 

OR  (TERMINATE-ENGAGEMENT-MODE) 

ALPHA*  TERM-ENGAGEMENT 
TERMINATE 
OR  (DROP-TRACK) 

SELECT  ENTITY-CLASS*  IMAGE  SUCH  THAT  CIMAGE.ID*HO-Id) 
IF  (FOUND) 

SUBNET*  RECORD-DROP 
ALPHA*  TERM-TRACk 
OUTPUT-INTERFACE*  DATA-RECOkD 
OTHERWISE 

ALPHA | CC-ERROR-PROCESSING 

terminate 

END 

OR  (CC-MESSAGE-ERROR) 

ALPHA*  CC-ERROR-PPOCESSING 
TERMINATE 

END 

ENO 

END, 


Figure  6-2  Sample  Use  of  APPEND  and  LIST  Commands  (Continued) 
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display  options  are  explained  below  using  the  following  hierarchy  definition: 

HIER  INF0_S0URCE  = INPUTJNTERFACE  PASSES  MESSAGE; 

MESSAGE  MADE  BY  FILE; 

MESSAGE  MADE  BY  DATA; 

FILE  CONTAINS  DATA; 

DATA  INCLUDES  DATA. 


MAP  Display  Option 

Either  of  the  following  statements  can  be  used  to  select  this 
option: 


LIST  ALL  BY  HIER  INFO_SOURCE. 

LIST  ALL  BY  HIER  INFO  SOURCE  BY  MAP. 


An  example  of  the  display  generated  by  this  option  is  given  in 
Figure  6-3.  The  following  rules  apply  when  listing  by  this  option. 

• An  element  is  displayed  if  and  only  if  it  is  a member  of 
the  set  identified  by  set  identifier  and  it  is  encountered 
while  traversing  the  hierarchy. 


• Elements  are  displayed  in  the  order  that  they  are  traversed 
in  the  hierarchy. 

• The  syntax  of  the  display  is  a special  form  that  is  not 
legal  RSL  syntax. 


• Elements  are  indented  according  to  the  level  in  the  hierarchy 
where  they  are  encountered. 

• The  only  associated  information  displayed  about  an  element  is 
the  binding  relationships  between  the  elements  in  the 
hierarchy.  Thus,  the  APPEND  selection  has  no  affect  when 
listing  with  this  option. 


SEQUENCE  Display  Option 

An  example  of  the  specification  of  this  statement  and  the  resulting 
display  is  provided  in  Figure  6-4.  The  following  rules  are  applied  to 
determine  the  format  and  content  of  displays  generated  when  this  option  is 
selected. 


• An  element  is  displayed  if  and  only  if  it  is  a member  of  the 
set  identified  by  set  identifier  and  it  is  encountered  while 
the  hierarchy  is  traversed. 
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(RADX  COMMANDS 

C t ST  ALL  BY  HIER  INFO.SOURCE  BY  MAP, 


INPUT. INTERFACE*  CC.IN 
PASSES 

MESSAGEl  handover 
made  by 

data*  commanded 

DAT  A I HO.IO 

data*  INITIAL.COVARIANCE 
DATA!  INITIAL.STATE 
MESSAGE*  mode.change 
made  by 

data*  COMMAND.Id 

MESSAGE*  TERMINATION 

made  by 

data*  COMMANDED 
data*  ho.id 

INPUT.INTERFACE*  RADAR.CLOCk.IN 

passes 

MESSAGEl  R.CLOCK.MESSaCE 
MADE  BY 

DATA*  RADAR.CL5CF.TIME 
INPUT. INTERFACE  I RADAR.IN 
PASSES 

MESSAGE*  T1.T2.RETURN 
MADE  BY 

FILE*  TI.T2.DATA 
CONTAINS 

DATA*  T1.T2.REC0RD 
INCLUDES 

DATA|  NOISE.LEVEL 
DAT  A | RANGE.MARK.INFORMATION 
INCLUDES 

DATA*  RANGE.MARK.TIME 
DAT* | SIGNAL. AMPLITUDE 

MADE  BY 


OATAI  RADAR.TYPE 
DATA*  RR.ORDER.lD 
DATA*  TI.T2.RECEIVE 
INCLUDES 

data*  alpha.erroR 

DATA*  BETA.ERROR 

DATA*  T1T2RTN.ERR0R.REP0RT 


INCLUDES 

DATA | REASON.FOR.TRANSMISSION.FAILURC 
data*  hake. array 
INCLUDES 

DAT  A | AVErAGE.SIGNAL.POnER 

DAT  A | THRESHOLD.DOWN.CROSSlNG.TIME 

DATA  | ThRESHOLD.UP.CROSSING.TIME 


Figure  6-3  Sample  LIST  By  MAP 


(RAQX  COMMANDS 

LIST  ALL  BY  HIER  INFO.SOURCE  BY  SEQUENCE, 


INPUT.INTERFACEI  cc„in, 

CONNECTS  TO | 

SUBSYSTEM!  SSC2. 

ENABLES! 

R»NETI  CC. RESPONSE , 

PASSES! 

MESSAGE!  HANDOVER 
MESSAGE!  MODE_CHAnGE 
MESSAGE!  TERMINATION, 

TRACED  FROM! 

OR IGINATJNG..REQUI RECENT ! 

TLS.DPSP«wPARAGRAPK,.3_2„l.A-.FUNCTlONAL_REQUIReMENTS 

ORIGINATING.REQUIRE^'-NTI 

TL3.DPSPR.SUBSECTI0N.3  2_1,FUNCTI0NAL.R£QUIREMENTS, 
REFERRED  BY! 

R„NET!  CC.RESPONSE, 

MESSAGE!  HANDOVER, 

MADE  BY! 

DATA!  COMMANDED 
DATA!  HO^ID 

datai  initialled variance 

DATA|  INITIAL^STAjE, 

PASSED  THROUGH! 

INPUT.INTERFACEI  cc.in, 

TRACFD  FROM! 

ORIGINATING.REQUIREMENTI 

TLS.DPSPR.PARAGRAPh-.3.2.1,.A.FUNCTI0NAL-REQUIREMENTs 

ORIGINATING.REQUIReMENTI 

TLS„DPSPR..PARAGRAPh»3-2-1.B„FUNCTI0NAL.REOUIREMENTs, 

DATA!  COMMANDED, 

LOCALITY!  LOCAL, 

RANGE  I 

"handover.image^orop^track^nitiate^engagement.mode, 

TERMINATE.ENGAGEMENT^moDE^C.MESSAGE.ERROR", 

TYPE!  ENUMERATION, 

USE!  BOTH, 

MAKES! 

MFSSAGE!  acknowledgement 

MESSAGE!  HANDOVER 
MESSAGE!  mODE.CHAnGE 
MESSAGE!  TERMINATION, 

INPUT  TO! 

ALPHA!  VAlIDATE.HeADER, 


Figure  6-4  Sample  LIST  By  SEQUENCE 
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• Elements  are  displayed  in  the  order  that  they  are  traversed 
in  the  hierarchy. 

• The  syntax  of  the  display  is  the  same  as  that  produced  by 
the  standard  LIST  command  which  is  an  indented  form  of  legal 
RSL  syntax. 

• Following  the  display  of  an  element,  associated  Information 
pertaining  to  the  element  is  displayed  as  selected  by  the 
APPEND  statement. 

GROUP  Display  Option 

Figure  6-5  gives  an  example  of  a statement  selecting  this  option  and 
the  output  generated  In  response  to  the  statement.  The  rules  that  are  used 
to  determine  the  type  of  display  produced  when  this  option  is  selected  are: 

• An  element  is  displayed  if  and  only  if  It  is  a member  of  the  set 
Identified  by  set  identifier  and  It  is  encountered  while 
traversing  the  hierarchy. 

• The  syntax  of  the  display  is  the  same  as  that  produced  by  the 
standard  LIST  corrmand  which  is  an  indented  form  of  legal  RSL 
syntax . 

• The  APPEND  option  is  applied  following  the  display  of  an  element 
to  determine  the  associated  information  that  should  be  displayed 
about  the  element. 

• A group  of  elements  encountered  while  traversing  the  hierarchy  starting 
from  an  element  in  the  top-of-the-hlerarchy  Is  displayed  in  an 
alphabetical  order  following  the  display  of  the  top-of-the- 
hlerarchy  element. 

A- summary  of  the  type  of  display  produced  by  each  of  the  options  described 
in  this  section  is  given  In  Table  6.2. 

6.2.4  Plotting  Structures 

This  command  is  used  to  generate  CALCOMP  plots  for  those  elements  which 
have  STRUCTURES.  The  syntax  of  the  statement  is: 

PLOT  <set  identifier  /<size  selection> 


The  set  Identifier  is  used  to  Identify  the  set  of  elements  to  be  plotted, 
and  of  course,  only  those  elements  (If  any)  which  have  structures  will  be 
plotted.  RADX  uses  the  same  basic  technique  for  generating  plots  as  that  used 
by  the  RNETGEN  function  described  in  Section  5.2.  Thus,  If  a structure  has 
ANAGRAPH  coordinates,  the  relative  position  of  the  structure  symbols  in  the 


11 


6-34 


(RADX  COMMANDS 

APPEND  ALL  PASSES#  PASSED#  MAKES / *<AOE  BY#  CONTAINS# 
CONTAINED,  INCLUDES#  INCLUDED* 


(RAD*  COMMAND* 

LIST  ALL  BY  HIFR  INF0_SOURCE  BY  GROUP, 


input_interfacei  cc„.in, 

PASSES! 

MESSAGE!  HANDOVER 
MFSSAGEl  MODE.CHAnGE 
MESSAGE!  TERMINATION, 

datai  commanded, 

MAKES! 

MESSAGE!  ACKNOWLEDGEMENT 
MESSAGE!  HANDOVER 
MESSAGE!  MOOE_CHAnGE 
MESSAGE!  TERMINATION, 

DATAj  H0_ID, 

MAKES! 

MESSAGE!  HANOOVER 
MESSAGE!  STATE.UPDATE 
MESSAGE!  TERMINATION 
MESSAGE!  TRAC K_ INITIATION 
MFSSAGEl  TRAC K„ TERMINATION, 

DATA!  INITIAL.COVARIANCE, 

MAKES! 

MESSAGE!  HANDOVER, 

DATA!  INITIAL.STATE, 

MAKES! 

MESSAGE!  HANDOVER 
MESSAGE!  TRACK.INITIATION, 

MESSAGE!  HANDOVER, 

PASSFD  THROUGH! 

INPUT.INTERPACEI  CC.IN, 

MADE  BY! 

DATAj  COMMAND^ID 
DATA!  HO.ID 

DATAj  INITIAL^COVARIANCE 
DATAj  INI TIAL.STATE, 

MESSAGE!  MODE.CHANGE , 

PASSED  THROUGH! 

imput.interfacei  CC.IN, 

MADE  BV| 

DATAj  COMMANO_IO, 


Figure  6-5  Sample  LIST  By  GROUP 
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Table  6.2  HIERARCHY  Display  Summary 


I 


plot  will  be  the  same  as  their  relative  position  when  displayed  on  the 
ANAGRAPH.  Should  a structure  not  have  coordinates,  the  automated  plotting 
procedure  is  used  for  assigning  (in  the  ASSM)  the  location  of  the  structure 
symbols.  The  size  of  a plot  is  determined  by  the  size  selection  specified 
by  the  user.  The  syntax  of  this  part  of  the  statement  is  given  below 
followed  by  the  rules  that  apply  to  the  processing  of  the  statement. 

(WIDTH  \]  r_-i  -1M. 

(height^  va1ue 

1.  The  value  of  the  WIDTH  parameter  specifies  in  inches  the 
width  of  the  plot. 


2.  The  value  of  the  HEIGHT  parameter  specifies  in  inches  the 
height  of  the  plot. 

3.  The  value  of  the  WIDTH  or  HEIGHT  parameter  can  be  a real  or 
integer  number  that  is  greater  than  zero.  If  the  value  of 
either  parameter  is  less  than  or  equal  to  zero,  an  error 
message  will  be  displayed  and  no  further  action  will  be  taken 
by  RADX. 

4.  If  the  WIDTH  parameter  is  not  specified,  then  8.0  is  used  for 
the  parameter  value. 

5.  If  the  HEIGHT  parameter  is  not  specified,  then  10.0  is  used 
for  the  value  of  the  parameter. 

6.  If  the  specified  value  of  the  WIDTH  parameter  is  greater 
than  50.0,  a diagnostic  message  will  be  issued  and  50.0  will 
be  used  in  place  of  the  specified  value. 

7.  If  the  specified  value  of  the  HEIGHT  parameter  is  greater  than 
29.0,  a diagnostic  message  will  be  issued  and  29.0  will  be 
used  in  place  of  the  specified  value. 


6.2.5  Listing  RSL  Descriptions 


A description  of  the  currently  defined  Requirements  Statement  Language  (RSL) 
can  be  acquired  from  the  ASSM  by  the  LIST  RSL  statement  which  offers  two  basic 
formats  for  generating  the  description. 

RSL  Definition 


The  format  of  this  display  contains  a syntax  that  is  legal 
RSL  extension  function  (see  Section  8).  The  syntax  of  the  RADX 
to  obtain  the  display  is: 


input  to  the 
sta tement 
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(list  I1 

\ PUNCH  fj 


RSL  [<display  item>]  . 


A list  of  allowed  forms  for  display  item  Is  given  next  with  a descrip- 
tion of  the  display  generated  when  the  display  item  is  used. 

element-type-name  - definition  of  the  element  type 

relationship-name  - definition  of  the  relationship 

attribute-name  - definition  of  the  attribute 


ELEMENTJYPE 

RELATION 

RELATIONSHIP 

ATTRIBUTE 


- definition  of  all  element  types 

- definition  of  all  relationships 


- definition  of  all  attributes 


ALL  - definition  of  all  element  types,  relationships, 

and  attributes.  (Assumed  value  when  display 
item  is  not  specified.) 

Examples  of  the  use  of  this  statement  and  the  displays  generated  by  it 
are  contained  in  Figure  6-6.  The  RSL  definitions  In  Appendix  D.3  of  this 
document  were  generated  using  the  command: 

LIST  RSL. 

RSL  Summary 

This  display  provides  a summary  of  the  legal  uses  of  an  element  type 
for  writing  RSL.  The  summary  is  not  a form  that  is  acceptable  to  the  RSL 
translator.  The  general  syntax  of  the  statement  that  invokes  the  summary  is 
given  below  and  examples  are  presented  in  Figure  6-7. 


(LIST  l1 
| PUNCH ^ 


RSL  [element-type-name]  SUMMARY. 


. 


In  the  statement,  the  element  type  name  identifies  a particular  RSL 
element  type  that  should  be  summarized.  If  an  element  type  is  not  specified 
in  the  statement,  then  a summary  for  all  element  types  is  generated. 

Appendix  D.4  of  this  document  was  generated  using  the  command: 

LIST  RSL  SUMMARY. 


(RAOX  COMMAND* 
LIST  RSL. 


element.typei  alpha 

(*  A PROCESSING  STEP  in  the  functional  requirements 

DOMAIN,  *), 

STRUCTURE  APPLICABILITY  I NET, 

element.typei  data 

(*  A SINGLE  ITEP  OR  SET  OF  DATA  THAT  IS  SPECIFIED 
AND  THAT  HILL  EIThER  BE  REQUIRED  IN  THE 

real-time  software  or  is  needeo  for 

DESCRIPTIVE  PURPOSES,  *), 

ELEMENT.TYPEI  DECISION 

(*  THE  DECISION  that  has  BEEN  MADE  TO  ENABLE 

REQUIREMENTS  to  Be  taken  FROM  The  dpspr  to  the  ppr, 
THIS  MEANS  that  the  REQUIREMENTS  are  not  SIMPLY 
ALLOCATED,  BIT  have  BEEN  SUBJECTED  TO 
DERIVATION,  *), 


IRADX  COMMAND* 

LIST  RSL  ENTEREO.BY, 


ATTRIBUTEI  enterfd.by, 

APPLICABLE  ELEMENT.TYPEI  ALPHA 

Data 

DECISION 

EntiTy.CLASS 

entity.type 

event 

PILE 

INPUT. interface 
HE  SS AGE 

ORIGInATING.REQUIREmENT 

OUTPUT-INTERFACE 

PERFORMANCE^REQUIREMENT 

P-NET 

SOURCE 

SUBNET 

SUBSYSTEM 

lnstruc  tured. requirement 

VALIDATION.PATH 

VAliDaTION.POINT 

VERSION, 

VALUEi  text 

(*  THE  IDENTITY  OF  The  last  person  to  enter 

INFORMATION  ABOUT  THE  ELEMENT,  O, 


Figure  6-6  Sample  LIST  RSL  Definition 
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(RADX  COMMAND* 
LIST  RSI  SUMMARY, 


element„typei  ALPHA 
LEGAL  RELATIONSHIPS! 

CREATES! 

entity.class 

DESTROYS! 

ENTITY..CLA3S 

FORMS! 

MESSAGE 

IMPLEMENTS! 

version 

INPUTS! 

DATA 

FILE 

OUTPUTS! 

DATA 

FILE 

SETS! 

ENTITY.TYPE 
documented  ("BY") I 
SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ("FROM")! 

DECISION 

ORIGINATING.REQUIREMENT 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement.approximatfly 

implement.precisely 

BETA! 

TEXT 

COMPLETENESS! 

INCOMPLETE 

complete 

CHANGEABLE 

DESCRIPTION! 

TEXT 

entered„byi 

TEXT 

GAMHAI 

TEXT 

element.typei  DATA 
LEGAL  RELATIONSHIPS! 

§ 


Figure  6-7  Sample  LIST  RSL  SUMMARY 


( R AD X COMMAND* 

LIST  RSL  DATA  SUMMARY, 


ElEMENT,TYPEl  DATA 
LEGAL  RELATIONSHIPS! 

DELAYS! 

EVENT 

IMPLEMENTS! 

VERSION 

INCLUDES! 

DATA 

MAKES! 

MESSAGE 

ORDERS! 

FILE 

ASSOCIATED  ("WITH")! 
ektity„cl*ss 
£NTITY_TYPE 
CONTAINED  ("IN")! 

FILE 

DOCUMENTED  ( "BY" ) I 
SOURCE 

EQUATED  ("TO")! 

SYNONYM 

INCLUDED  ( " IN"  ) | 

DATA 

INPUT  ("TO")! 

ALPHA 

OUTPUT  ( "FROM" ) | 

alpha 

RECORDED  ("BY")! 

VALIDATIO  N—P  0 1 N T 
TRACED  ("FROM")| 

DECISION 

ORIGINATI NG_REQU I REMEN T 
LEGAL  ATTRIBUTES! 

ARTIF ICIALITYI 
ARTIFICIAL 
VALIDATION 

implement.approximately 

IMPLEMENT.PRECISELY 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

CHANGEABLE 

DESCRIPTION! 

TEXT 

enteped.byi 

TEXT 

I N I T I A|._VALUE  I 
NA^ED 
NUMERIC 

Figure  6-7  Sample  LIST  RSL  SUMMARY  (Continued) 
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This  statement  is  used  to  obtain  a listing  of  the  control  and  extension 
permissions  that  are  active  for  the  ASSM  being  used  by  REVS.  The  syntax  of 
the  statement  is: 


(LIST 
| PUNCH 


PERMISSION  GIVEN  control -permission-name. 


The  control  permission  name  must  be  the  name  of  a control  permission  that 
has  been  established  using  the  extension  portion  of  the  RSL  translator.  If 
it  is  not,  the  command  will  be  rejected.  If  it  is,  RADX  will  display  the 
RSL  statement  CONTROL_PERMISSION  with  the  given  name  and  will  generate  the 
RSL  statements  for  all  other  permissions  in  the  ASSM,  should  any  exist. 
Figure  6-8  contains  examples  of  this. 


As  Indicated  in  the  previous  portions  of  this  section,  anything  that 
can  be  LISTed  by  RADX  can  also  be  PUNCHed.  This  allows  a data  base  to  be 
stored  in  "source  form"  instead  of  "data  base  form",  two  or  more  data  bases 
to  be  merged,  or  a requirements  data  base  to  be  moved  from  one  REVS 
installation  to  another. 


The  REVS  Executive  and  RADX  have  special  provisions  to  allow  informa- 
tion to  be  PUNCHed.  The  value  of  a parameter  of  the  REVSXQT  macro  as 
described  in  Section  9 actually  controls  the  disposition  of  PUNCHed  Images. 


After  Information  has  been  PUNCHed,  it  can  be  input  to  the  RSL 
Translator.  If  the  information  is  on  cards,  then  obviously  the  cards 
serve  as  the  input  source.  If  the  information  has  been  placed  on  a file, 
then  the  file  can  be  the  input  source  by  using  the  REVS  Executive  ADDFILE 
capability  that  is  documented  in  Section  4.2.2. 


(RADX  COMMAND* 

LIST  PERMISSION  GIVEN  CH4NGE.ANo.EXTEnSION.CONTROLLER, 


CONTROL— PERMISSION  CHANGE.ANd.EXTEnSION.CONTROLLER, 
CONTROL-Pf RmISSION  CONTROLLER.  J , 

CONTROL-PERMISSION  CONTROLLER.2, 

EXTENSION. PERMISSION  E X TENDER.  1, 
EXTENSION.PFRMISSION  EXTENDEr.2, 

EXTENSION.PE  RMISSION  EX  TENDER. 3, 

[RADX  COMMAND* 

LIST  PERMISSION  GIVEN  CONTROLLER. 1 t 


CONTROL-PERMISSION  CONTR0LLER.1  , 

CONTROL-PERMISSION  ChAMGE.ANo.EXTEnSION.CONTROLLER , 
CONTROL-PERMISSION  CONTROLLEr.2, 

EX  TENS I ON.PFRMI SSI  ON  EXTENDER.1, 
EXTENSION-PERMISSION  FXTENDEr.2, 
EXTENSION.PFRMISSION  EXTENOEr.3, 

(RADX  COMMAND* 

LIST  PERMISSION  GIVEN  EXTENOER.l, 


•ERROR  2580  ILLEGAL  PERMISSION  SPECIFIED, 
SYMBOL  FXTENDER.l 

(RADX  COMMAND* 

LIST  PERMISSION  GIVEN  N0T.A_NEEd.TO-,KNOW  , 


• ERROR  2580  ILLEGAL  PERMISSION  SPECIFIC, 
SYMBOL  NOT.A_NEED.TO.KNOW 


Figure  6-8  Sample  LIST  PERMISSION 
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The  user  should  be  cautious  to  only  Input  Information  to  the  RSL 
translator  that  Is  PUNCHed  by  RADX  as  legal  RSL.  The  following  are  the 
recommended  statements  to  be  used  for  PUNCHIng  the  RSL  definition  and  the 
requirements  specification  when  they  are  intended  to  be  input  to  the  RSL 
translator. 

PUNCH  RSL. 

APPEND  ALL:  ATTRIBUTE,  PRIMARY,  STRUCTURE. 

PUNCH  ALL. 


6.3  USING  AUTOMATED  STATIC  ANALYSIS 

This  section  describes  the  automated  static  analysis  that  is  provided 
by  RADX.  There  are  two  basic  types  available  to  the  user.  The  first  Is  a 
consistency  check  of  critical  relationships  and  attributes  specified  In  the 
ASSM.  The  second  Is  a data  flow  analysis  within  an  R_NET.  The  selection 
to  perform  a data  flow  analysis  also  causes  the  consistency  test  to  be  per- 
formed. Another  function  of  this  area  of  RADX  is  to  perform  the  consistency 
check  and  collect  Information  from  the  ASSM  during  initialization  of  the 
SIMGEN  function.  There  are  no  requirements  on  the  user  to  cause  this  but 
there  Is  a need  to  know  about  it  so  that  certain  information  displayed  during 
SIMGEN  execution  can  be  understood.  This  will  be  further  explained  In  this 
section. 

The  actual  error  messages  that  can  occur  from  an  analysis  are  given  In 
Appendix  F.2.  The  discussion  that  follows  provides  a general  statement  of 
the  types  of  errors  detected,  an  interpretation  of  analysis  displays,  and  a 
description  of  the  RCL  used  to  Invoke  an  analysis. 

6.3.1  Consistency  Analysis 

The  syntax  for  activating  the  automated  consistency  analysis  Is: 


(IMPLIED)1 

ANALYZE  <set  Identifier  USING  < BETA  > |. 

(GAMMA  1 


The  set  Identifier  is  the  identification  of  a collection  of  R_NETs 
to  be  analyzed.  The  set  may  contain  elements  other  than  R_NETs  but  their 
Inclusion  will  not  Influence  the  analysis.  The  optional  part  of  the 
statement  specifies  the  type  of  DATA  to  be  used  during  the  analysis.  Should 
no  option  be  selected,  IMPLIED  DATA  Is  used.  The  meaning  of  each  of  the 
options  Is: 

IMPLIED  - Ignore  the  USE  attribute  and  use  the  lowest  level 

DATA  in  the  ASSM  (i.e.,  DATA  that  does  not  INCLUDE  other 
DATA). 

BETA  - use  DATA  with  USE  BETA. 

GAMMA  - use  DATA  with  USE  GAMMA. 
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When  USING  BETA  or  USING  GAMMA  Is  selected,  the  USE  attribute  test 
described  below  Is  performed  to  Identify  anomalies  that  result  from  the 
specification  of  the  USF  attribute  and  conflicting  relationships. 

Analysis  Information  Network 

The  initial  output  from  an  analysis,  either  user  activated  or 
SIMGEN  activated.  Is  the  display  of  the  information  to  be  used  In  the 
analysis.  For  the  case  of  SIMGEN  activation.  It  is  also  a display  of  the 
Information  to  be  simulated.  An  example  of  the  display  is  given  In 
Figure  6-9.  The  format  Is  similar  to  that  generated  when  the  MAP  option 
is  selected  In  a LIST  HIERARCHY  command  (Section  5.2.3).  The  exception 
is  that  when  the  character  string,  (*),  appears  after  an  element  name.  It 
indicates  that  the  pertinent  Information  about  the  element  has  previously 
been  displayed  in  the  Information  network  and  Is  not  repeated. 

Loop  Detection 

As  the  Information  network  Is  generated  a test  Is  performed  to 
identify  loops  that  may  occur  In  the  network.  A loop  can  be  caused  by 
a direct  or  indirect  reference  between  SUBNETS  and  a recursive  definition 
of  a DATA  element  via  the  INCLUDES  relationship.  An  example  Is  DATA  X 
INCLUDES  DATA  Y and  DATA  Y INCLUDES  DATA  X.  When  such  an  error  Is 
detected,  a message  is  Issued  and  the  path  of  elements  containing  the  loop 
is  displayed. 

USE  Attribute  Test 

This  test  is  performed  if  the  option  USING  BETA  or  USING  GAMMA  is 
selected  or  If  the  analysis  is  activated  from  SIMGEN  which  always  requires 
that  either  BETA  or  GAMMA  be  chosen  for  analysis  and  simulation. 

The  following  Is  a list  of  the  errors  that  can  be  detected  by  this  test 
when  they  occur  while  analyzing  DATA  with  USE  BETA. 

1.  The  lowest  level  DATA  that  Is  needed  for  the  BETA  analysis 
does  not  have  a USE  attribute.  A message  is  Issued  and  the 
DATA  Is  used  In  the  analysis. 

2.  The  lowest  level  DATA  required  for  the  BETA  analysis  has  USE 
GAMMA.  A message  Indicates  that  It  should  have  USE  BETA  or 
USE  BOTH.  The  item  is  used  for  the  analysis. 

f I 
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(RADX  COMMAND* 

analyze  oata.flow  all  USING  beta» 


R.NETl  CC.RESPONSE 
REFERS  TO 

ALPHA i ACKNOWLEDGE 
FORMS 

MESSAGE!  ACKNOWLEDGEMENT 
MADE  BY 

DAT  A | COMMANDED 
ALPHA**  CC.ERROR.PROCESSING 
ALPHA!  ENGAGEMENT„INItIATION 
OUTPUTS 

DATA!  MODE 
ALPHA!  STARTER 
OUTPUTS 

FILE!  WAVEF0RM.TABLE 
CONTAINS 

DATA!  WF„CHARACTERISTICS 
DATA!  WF.nAME 
ALPHA!  TERM.ENGAGEMENT 
OUTPUTS 

DATA!  MODE 
ALPHA!  TERM_TRACK 
OUTPUTS 

FILE!  TERMINATOR 
contains 

DATA!  DROP.REASON 
DATA*  DROp.TIME 

INPUTS 

DATA!  CLOCK.TIME 
DATA  I DROP.REASflK 
DATA!  DROP.TIME 
OUTPUTS 

DATA!  DATA.RECOrD.TYPE 
DATA!  RE  ASON.F0R.DROP 
DATA!  TIME.OF.OROP 
FORMS 

MESSAGE!  TRACK.TERMINATION 
MADE  BY 

DATA!  DATa.REC0RD.TYRE 
DATA!  HO.ID 
DATA|  REAsON_FOR.J)ROP 
DATA!  TIME.OF.DROP 
ALPHA!  TRACK. INITIATE 
INPUTS 

DATA!  CLOCK.TIME 
DATA!  HO.ID 

DATA!  INITIAL. COVARIANCE 
DATA!  INITIAL.STATE 


data.record.tyre 

HO.ID 

REAsON.FOR.DROP 

TIME.OF.DROP 


DATA! 
DATA! 
DATA! 
DATA! 
OUTPUTS 
DA**  I 

r 


COVARIANCE 

DATA.RECOrD.TYPE 


Figure  6-9  Sample  Analysis  Information  Network 


/ 


3.  A DATA  element  with  USE  BETA  either  directly  or  Indirectly 
INCLUDES  other  DATA  with  USE  BETA.  The  highest  level  element 
Is  used  in  the  analysis  and  the  user  is  Informed  of  the  problem. 
However,  should  there  be  another  need  for  the  lower  level  DATA 
item  that  does  not  go  through  the  higher  level  item,  the  lower 
level  item  will  be  selected  for  analysis  in  addition  to  the 
previously  selected  higher  level  element. 

When  an  analysis  is  done  for  DATA  with  USE  GAMMA  the  test  and  actions 
listed  next  are  performed. 

1.  A DATA  item  required  for  the  GAMMA  analysis  does  not  have  a 
USE  attribute.  The  situation  is  reported  to  the  user  and 
the  DATA  is  used  for  analysis. 

2.  A DATA  item,  with  USE  GAMMA  or  USE  BOTH,  INCLUDES  other  DATA. 

The  appropriate  error  message  is  Issued  and  the  analysis  is 
performed  without  the  item. 

3.  A lowest  level  DATA  element  has  USE  BETA.  A message  which 
indicates  that  it  should  have  USE  BOTH  or  USE  GAMMA  is  generated 
and  the  element  is  used  in  the  analysis. 

LOCALITY  Attribute  Test 


This  test  checks  the  correct  use  of  the  LOCALITY  attribute.  It  is 
concerned  with  the  DATA  and  FILE  elements  that  are  members  of  Repetitive 
Data  Sets  (RDS).  The  RSL  elements  that  make  an  RDS  are  MESSAGE,  ENTITY_ 
CLASS,  ENTITY_TYPE,  and  FILE.  The  elements  that  can  be  assigned  a LOCALITY 
are  DATA  and  FILE.  The  value  of  LOCALITY  can  be  GLOBAL  or  LOCAL.  The 
LOCALITY  of  an  RDS  (other  than  a FILE)  and  its  members  Is  not  optional. 

They  are:  LOCALITY  of  MESSAGE  is  LOCAL;  LOCALITY  OF  ENTITY_CLASS  is 
GLOBAL;  LOCALITY  of  ENTITYJYPE  Is  GLOBAL.  The  LOCALITY  of  a DATA  or  FILE 
element  is  GLOBAL  if  It  is  not  contained  In  an  RDS  that  dictates  Its  value 
and  no  LOCALITY  is  specified.  Based  on  these  facts, the  following  test  and 
actions  are  performed  in  the  order  that  they  are  listed: 

1.  If  the  Information  content  (i.e.,  FILE  or  DATA)  of  a MESSAGE 
has  an  explicit  declaration  of  LOCALITY  GLOBAL,  an  error 
message  Is  Issued  identifying  the  conflict.  For  analysis 
purposes,  all  the  Information  In  the  MESSAGE  Is  considered 
to  be  LOCAL,  regardless  of  the  LOCALITY  attribute. 

2.  If  the  members  of  an  ENTITYjCLASS  or  ENTITY  TYPE  have  been 
assigned  LOCALITY  LOCAL,  the  error  Is  identTfied  and  all  the 
members  are  treated  as  GLOBAL. 


I 
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If  the  specified  LOCALITY  of  the  DATA  In  a FILE  differs 
from  the  specified  or  defaulted  LOCALITY  of  the  FILE,  then 
an  error  message  is  generated  which  Identifies  the  problem 
and  the  LOCALITY  of  the  DATA  is  considered  to  be  the  same  as 
the  LOCALITY  of  the  FILE. 


Membership  Test 


This  test  identifies  those  DATA  items  that  are  members  of  more  than 
one  Repetitive  Data  Set.  An  error  of  this  nature  can  possibly  cause 
multiple  error  messages  to  be  produced  about  the  LOCALITY  of  an  element. 

For  this  reason,  the  errors  of  the  membership  category  should  be  examined 
to  see  If  they  are  triggering  LOCALITY  errors.  The  following  summarizes 
the  specific  tests  that  are  performed.  It  Is  indeterminant  what  effect 
the  errors  will  have  on  the  analysis  or  simulation  of  the  requirements 
data  base  that  contains  any  of  these  errors.  An  error  will  be  identified 
if  any  of  the  following  conditions  occur: 

1.  A DATA  MAKES  a MESSAGE  and  is  CONTAINED  In  a FILE  but  the 
MESSAGE  is  not  MADE  by  the  FILE. 

2.  A DATA  is  CONTAINED  in  more  than  one  FILE. 

3.  A DATA  is  CONTAINED  In  a FILE  and  is  ASSOCIATED  with  an 

ENTITY  TYPE  or  ENTITY  CLASS  but  the  FILE  is  not  ASSOCIATED 
with  the  ENTITYJYPE  or  ENTITYJLASS. 

4.  A DATA  MAKES  a MESSAGE  and  is  ASSOCIATED  with  an  ENTITYJYPE 
or  ENTITY_CLASS. 

5.  A DATA  Is  ASSOCIATED  with  more  than  one  ENTITY_CLASS. 

6.  A DATA  is  ASSOCIATED  with  more  than  one  ENTITYJYPE  that 

does  not  COMPOSE  the  same  ENTITYJLASS. 

6.3.2  Data  Flow  Analysis 

The  option  to  perform  a consistency  analysis  and  a data  flow  analysis 
is  selected  using  the  following  syntax: 


ANALYZE  DATA  FLOW  <set  identifiers 


USING  | 


IMPLIED 

BETA 

GAMMA 


The  meaning  of  the  set  identifier  and  the  optional  part  of  the  state- 
ment is  the  same  as  the  description  in  Section  6.3.1.  When  this  command  Is 
specified,  the  consistency  analysis  tests  are  performed  and  an  analysis  of 
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the  use  and  assignment  of  Information  based  on  the  predecessor/successor 
relationships  of  the  nodes  within  an  R_NET  and  dependent  SUBNET  structures 
Is  performed.  The  actual  tests  made  by  the  data  flow  analysis  can  be  grouped 
into  the  following  classes. 

1.  The  Incomplete  or  ambiguous  specification  of  branch  conditions 
In  a structure. 

2.  Net  structure  errors. 

3.  The  incorrect  assignment  and  use  of  Information. 

4.  The  ambiguous  Identification  of  Information  that  Is  assigned 
or  used  In  parallel  paths. 

Walk-Back  From  Error  Source 

When  a data  flow  error  is  detected,  a message  is  generated  that 
describes  the  nature  of  the  error.  For  most  messages,  additional  informa- 
tion that  identifies  the  element  or  elements  which  caused  the  error  is 
displayed  after  the  message.  After  this,  a walk-back  from  the  node  in  the 
structure  where  the  error  was  detected  to  the  first  node  of  the  R_NET  being 
analyzed  is  produced  to  aid  the  user  in  locating  the  source  of  the  error. 

An  example  of  how  this  will  appear  in  the  output  is: 

* ERROR  2664  INFORMATION  ALWAYS  USED  BEFORE  ASSIGNED. 

DATA:  WLFE04. 

* ERROR  DETECTED  AT  ALPHA:  ALPHA7H 

* PRECEDED  BY  AND-NODE 

* PRECEDED  BY  AND-NODE 

* PRECEDED  BY  ALPHA:  ALPHA7 

* PRECEDED  BY  R_NET:  RNET7 

Conditional  Branch  Test 

The  errors  detected  by  this  test  are  those  which  occur  at  a CONSIDER 
OR  node.  The  following  are  the  conditions  that  must  hold  for  the  node. 

If  any  are  violated,  an  appropriate  error  message  is  issued. 

1.  The  element  that  is  the  subject  of  the  CONSIDER  must  be  of 
element  type  DATA  or  ENTITY_CLASS. 

2.  If  the  CONSIDER  element  is  DATA,  then  it  must  have  TYPE 
ENUMERATION  and  a value  for  the  RANGE  attribute. 

3.  A value  that  appears  in  the  RANGE  attribute  cannot  duplicate 
another  value  and  it  must  not  be  the  same  as  a name  in  the 
ASSM. 
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4.  If  the  CONSIDER  element  is  an  ENTITY  CLASS,  there  must  be 
Instances  of  the  COMPOSED  relationshTp  for  the  element. 

5.  The  values  that  appear  in  branch  expressions  from  the 
CONSIDER  node  must  be  legal  for  the  element  being  considered. 

For  example,  if  an  ENTITY  CLASS  is  being  considered,  only 
ENTITY JYPEs  which  COMPOSE  the  ENTITY_CLASS  can  be  in  the 
branch  expressions.  For  DATA  of  TYPE  ENUMERATION,  the  value 
must  be  in  the  RANGE  attribute. 

6.  The  values  in  the  branch  expressions  must  include  all  the 
possible  values  of  the  considered  element. 

7.  A value  can  only  occur  once  in  all  of  the  branch  expressions. 

Net  Structure  Test 

The  RSL  Translation  and  the  Interactive  R-Net  Generation  functions 
ensure  that  a single  R_NET  or  SUBNET  structure  is  legal  before  it  is  entered 
in  the  ASSM.  There  are  two  problems  that  go  intentionally  undetected  until 
data  flow  analysis.  One  is  the  slmplediagnosis  of  a SUBNET  without  a 
structure  that  is  directly  or  indirectly  referenced  by  an  R_NET  being  analyzed 
or  simulated.  The  second  is  the  detection  of  partially  rejoining  logic 
constructs  which  result  from  SUBNET  expansion  in  a referencing  structure. 

This  problem  can  occur  for  both  AND  and  OR  constructs.  Figure  6-10  Illustrates 
a partially  rejoining  AND  construct  that  occurs  when  SUBNET  S Is  expanded 
into  R_NET  R. 

Information  Assignment/Usage  Test 

Based  on  the  predecessor/successor  relationships  of  nodes  In  a 
structure,  this  test  identifies  errors  that  result  from  the  use  of  Informa- 
tion that  does  not  have  a source  and  the  assignment  of  information  that  Is 
not  used.  The  term  Information  is  applied  in  a general  sense  to  refer  to 
the  following  element  types:  DATA,  FILE,  MESSAGE,  INPUTJNTERFACE,  0UTPUT_ 
INTERFACE,  ENTITY_CLASS,  and  ENTITYJYPE.  Information  is  considered  to  be 
used  at  a node  if  Its  value  is  required  to  compute  Information,  to  make  a 
branch  decision,  to  Identify  other  information,  or  PASS  an  OUTPUT_INTERFACE. 
Information  is  assumed  to  have  a source  If  it  has  an  INITIAL_VALUE,  exists 
external  to  the  R-Net  being  analyzed  (i.e.,  LOCALITY  GLOBAL  or  acquired  from 
an  INPUTJNTERFACE),  Is  OUTPUT  by  an  ALPHA,  or  is  a member  of  a properly 
maintained  Repetitive  Data  Set.  The  operations  used  to  maintain  a Repetitive 
Data  Set  are  FORM,  CREATE,  DESTROY,  SET,  SELECT,  and  FOR  EACH. 
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Figure  6-IO  Sample  Partially  Rejoining  AND-Construct 


The  detected  errors  are  segmented  as  to  whether  they  will  always 
occur  at  a node  or  whether  they  will  only  occur  for  some  paths  that 
precede  the  node.  For  the  latter  case,  the  word,  SOMETIMES  or  POSSIBLY, 
will  appear  in  error  messages  to  make  the  distinction.  The  following 
summarizes  the  conditions  that  will  be  diagnose^  by  this  test. 

1.  The  use  of  LOCAL  simple  DATA  that  does  not  have  an  INITIAL 

VALUE  and  has  not  been  assigned  by  a predecessor  ALPHA. 

2.  The  use  of  information  ASSOCIATED  with  an  ENTITY_TYPE  or 
ENTITY_CLAS$  that  Is  not  Identified. 

3.  The  use  of  information  CONTAINED  in  a FILE  that  is  not 
identified. 

4.  The  assignment  of  LOCAL  information  that  is  not  used  in  a 
successor  node.  This  includes  a FORMed  MESSAGE  that  cannot 
PASS  an  OUTPUTJNTERFACE. 

5.  The  assignment  of  LOCAL  information  that  is  reassigned  before 
It  is  used  in  a successor  node. 

6.  A SET  ENTITY_TYPE  that  is  not  preceded  by  a CREATE,  SELECT, 
or  FOR  EACH  operation  on  the  ENTITY_CLASS  that  is  COMPOSFl 
of  the  ENTITY_TYPE. 

7.  A DESTROY  ENTITY_CLASS  that  is  not  SELECTED. 

8.  The  use  of  information  from  more  than  one  INPUT_INTERFACE 
MESSAGE  on  the  same  path. 

9.  The  selection  of  a new  ENTITY_CLASS  without  a COMPOSED 
ENTITY  TYPE  being  SET  for  the  current  ENTITY_CLASS  following 
a CREATE  operation. 

10.  The  traversal  of  an  OUTPUTJNTERFACE  without  a FORMed  MESSAGE 
that  can  PASS  the  INTERFACE. 

11.  Information  passing  an  INPUTJNTERFACE  is  not  used. 


Ambiguous  Flow  Test 

For  the  purpose  of  this  test,  an  R_NET  is  considered  to  contain  an 
ambiguous  data  flow  specification  if  a change  in  the  sequence  of  execution 
of  parallel  paths  causes  the  source  of  information  for  a node  to  change. 

It  is  possible  that  such  a condition  has  been  Intentionally  specified  and 
is  not  a true  error.  However,  the  ambiguity  will  always  be  identified  and 
It  Is  the  user's  responsibility  to  access  the  Impact  on  the  requirements. 

Examples  of  this  type  of  error  are  illustrated  below. 
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In  both  of  the  R_NETs  the  source  for  DATA  X that  is  INPUT  to  ALPHA  B 
can  either  be  ALPHA  A or  ALPHA  C depending  on  the  order  that  the  parallel 
paths  are  exercised.  For  R_NET  P,  RADX  would  Inform  the  user  of  the  problem 
by  displaying  the  fact  that  DATA  X is  assigned  and  used  on  different  parallel 
paths.  The  message  triggered  by  R_NET  Q would  inform  the  user  that  DATA  X 
Is  assigned  from  more  than  one  parallel  path. 
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7.0  SIMULATING  REQUIREMENTS 

REVS  supports  generation  and  execution  of  simulators  of  the  data  pro- 
cessing system  based  on  the  requirements  stated  in  RSL  and  stored  in  the 
data  base  (the  ASSM).  The  simulators  are  discrete  event  and  are  of  two 
distinct  types.  The  first,  a functional  or  beta  simulation,  uses  models 
of  the  processing  steps,  the  ALPHAS.  These  models  may  employ  shortcuts 
and  use  models  of  the  true  data  to  simulate  the  required  processing.  This 
type  of  simulation  serves  as  a means  to  validate  the  overall  flow  of  pro- 
cessing against  higher  level  system  requirements. 

The  other  type  of  simulation,  an  analytic  or  gamma  simulation,  uses 
analytic  models,  i.e.,  models  that  employ  algorithms  similar  to  those 
which  will  appear  in  the  software.  A gamma  simulation  may  be  used  to 
define  a set  of  data  processing  algorithms  which  have  the  required  accuracy 
and  stability.  This  does  not  establish  real-time  feasibility  of  the  algorithm 
set  for  a particular  implementation;  instead  It  provides  an  existence  proof 
of  an  analytic  solution  to  the  problem. 

For  gamma  simulations,  REVS  will  also  generate  a simulation  post  pro- 
cessor containing  the  PERFORMANCE_REQUIREMENT  TESTs  specified  in  the  ASSM. 

The  post  processor  tests  are  executed  against  data  recorded  from  a gamna 
simulation  to  establish  the  analytic  feasibility  that  the  set  of  algorithms 
will  meet  the  performance  required  of  the  data  processing  system. 

As  stated  above,  the  distinction  between  beta  and  gamma  simulations 
is  the  ALPHA  models  and  the  degree  to  which  the  required  DATA  is  modeled. 

In  a gamma  simulator,  all  of  the  requirements  DATA  (I.e.,  lowest  level  of 
DATA)  is  present;  in  a beta  simulator,  only  those  DATA  with  USE  BETA  or 
USE  BOTH  are  used.  Thus,  for  a given  ASSM  the  remainder  of  the  simulator 
(processing  flow  and  data  structures)  remains  constant. 

The  ASSM  representation  of  t ,e  requirements  Is  translated  Into 
simulator/post  processor  code  In  the  programming  language  PASCAL.  The 
flow  structure  of  each  R_NET  and  SUBNET  is  used  to  develop  a PASCAL  pro- 
cedure whose  control  flow  Implements  that  of  the  net  structure.  Each 
ALPHA  reference  on  the  nets  becomes  a call  to  a PASCAL  procedure  containing 
either  the  model  (BETA)  or  algorithm  (GAMMA)  for  the  ALPHA.  The  data 
definitions  and  structure  for  the  simulator  are  synthesized  from  the 


requirements  DATA  and  their  relationships  and  attributes  specified  In  the 
ASSM.  Based  on  this  Information,  data  management  and  recording  procedures 
are  synthesized.  This  software  generated  based  on  the  ASSM  Is  consolidated 
with  simulation  utilities  and  a driver  to  construct  the  simulator. 

In  generating  a post  processor,  the  PERFORMANCE_REQU IREMENT s TESTs 
In  the  ASSM  are  translated  into  PASCAL  procedures.  The  data  definitions 
and  structures  for  the  post  processor  and  the  retrieval  procedures  for 
accessing  data  recorded  by  the  simulator  are  synthesized  from  the  ASSM  re- 
lationships and  attributes  of  RECORDED  DATA.  These  are  consolidated  with 
control  utilities  to  generate  a post  processor.  The  dependencies  of  the 
simulator  and  post  processor  on  the  RSL  concepts  are  further  described  In 
Section  7.1,  as  are  the  rules  for  writing  BETAs,  GAMMAs,  and  TESTs. 

A simulator  and  post  processor  are  built  by  the  REVS  Simulator  Genera- 
tion (SIMGEN)  function.  Through  SIMGEN  commands  (See  Section  7.3),  the  user 
controls  the  type  of  simulation.  Its  scope,  and  Its  Identification.  After 
first  internally  Invoking  the  RADX  ANALYZE  capability,  discussed  In  Section 
6.3,  to  analyze  the  ASSM,  SIMGEN  performs  the  translation  and  consolidation 
described  above  and  establishes  conditions  which  will  cause  the  simulator 
(and  post  processor)  to  be  compiled  (see  Section  9.0  for  the  REVS  job  control 
stream). 

A REVS  generated  simulator  is  composed  of  the  following  major  components, 
as  shown  In  Figure  7-1: 

• R_NET  procedures 

• Simulation  Executive 

t Simulation  Event  Manager 

• Simulation  Data  Manager 

• Simulation  driver. 

The  simulator  Is  of  the  discrete  event  type  and  Is  designed  to  Inter- 
face the  R_NET  procedures  with  a simulation  driver  to  form  a '•osed-loop 
simulation.  Overall  simulation  control  and  the  engagement  clock  reside  In 
the  Simulation  Executive.  The  driver  Interfaces  with  the  R_NET  procedures 
through  the  Simulation  Data  and  Event  Managers. 
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Figure  7-1  Simulator  Functional  Components 


An  R_NET  Is  the  only  element  In  RSL  which  can  be  scheduled  for  execu- 
tion in  a simulator.  An  R_NET  is  scheduled  to  execute  whenever  flow  passes 
through  an  EVENT  which  ENABLES  the  R_NET  or  when  a MESSAGE  PASSES  an  INPUT_ 
INTERFACE  which  CONNECTS  to  the  data  processing  subsystem  and  ENABLES  the 
R_NET.  A component  of  the  driver  representing  a SUBSYSTEM  Is  scheduled  to 
execute  whenever  a MESSAGE  Is  PASSED  through  an  0UTPUT_I NTERFAC E which 
CONNECTS  to  a SUBSYSTEM.  The  Simulation  Event  Manager  provides  the  utilities 
to  schedule  the  execution  of  both  R_NETs  and  SUBSYSTEM  models.  The  Emula- 
tion Data  Manager  controls  and  provides  access  to  the  MESSAGES  which  are 
PASSED  through  the  Interfaces,  as  well  as  managing  all  other  RSL  DATA  con- 
structs. The  Simulation  Executive  controls  the  execution  of  the  simulator  by 
causing  control  to  pass  to  the  driver  models  and  the  R_NET$  at  the  scheduled 
times.  Details  of  interfacing  a driver  with  the  simulated  R_NETs  are  pro- 
vided In  Section  7.2. 

A REVS  generated  post  processor  consists  of  a post  processor  controller, 
data  retrieval  procedures,  and  PERFORMANCE_REQUIREMENTs  TESTs  translated  Into 
executable  PASCAL  functions.  Once  generated,  the  simulators  and  post  pro- 
cessors are  accessible  for  execution  through  the  REVS  Simulation  Execution 
(SIMXQT)  and  Simulation  Data  Analysis  (SIMDA)  functions.  The  user  controls 
available  through  SIMXQT  and  SIMDA  are  described,  respectively.  In  Sections 
7.4  and  7.5. 


7.1  PREPARING  AN  ASSM  FOR  SIMULATION 


In  generating  a simulator  and  post  processor  from  the  ASSM,  REVS  uses 
the  RSL  concepts  comprising  the  Data,  Alpha,  R-Net  and  Validation  Segments 
(see  Sections  3.1  through  3.4,  respectively).  The  concepts  are  either 
directly  represented  in  the  simulator  or  used  in  its  generation.  All  of 
the  concepts  In  these  segments  are  pertinent  with  the  exceptions  of  the 
DATA  attributes  MAXIMUMJALUE,  MINIMUMJALUE,  RESOLUTION,  and  UNITS  and  of 
the  VALIDATION_PATH  attributes  MAXIKUM_TIME  and  MINIMUM_TIME. 

To  generate  meaningful  simulators,  the  conventions  associated  with 
the  concepts  (as  explained  in  Section  3)  must  be  followed.  It  Is  further 
necessary  that  the  requirements  pertinent  to  functional  flow  have  been 
completed  (for  example,  that  each  Interface  CONNECTS  to  a SUBSYSTEM,  each 
R_NET  is  ENABLED,  and  each  interface  PASSES  MESSAGES).  Also,  as  described 
In  Section  5,  the  names  for  requirements  elements  should  have  been  selected 
to  conform  to  the  Installation  dependent  naming  requirements  described  In 
Section  10  and  so  as  not  to  conflict  with  BETA/GAMMA,  TEST,  and  PASCAL  reserved 
words  (see  Appendix  B).  REVS  will  always  build  a simulator  even  If  the  resulting 
simulator  Is  not  meaningful  because  of  omissions  or  anomalies  In  the  ASSM;  the 
simulator  will  have  the  same  omissions  and  anomalies. 

Where  possible,  REVS  provides  defaults  In  the  simulation  generation 
process:  If  an  R_NET  or  SUBNET  structure  is  omitted,  REVS  will  generate  a 
"dummy"  procedure  representing  an  empty  structure;  if  a BETA  or  GAMMA  Is 
omitted,  REVS  will  provide  one  (see  Section  7.2.1);  if  certain  attributes 
of  DATA  such  as  TYPE  or  INITIAL_VALUE  are  not  specified,  default  values  will 
be  used  in  the  simulator. 

In  generating  a simulator,  the  ANALYZE  function  of  RADX  Is  first  auto- 
matically executed  to  analyze  errors  and  to  identify  default  action  where 
possible.  Where  the  user  does  not  follow  the  conventions  of  RSL,  RADX 
will  attempt  to  diagnose  the  problem  (see  Section  6.3)  but  cannot  correct 
the  error;  thus  an  erroneous  simulator  will  be  generated.  Consequently, 
before  generating  a simulator,  it  is  recomnended  that  the  user  run  the  RADX 
package  described  in  Section  6.1.8,  execute  the  data  flow  analysis  capability 
of  RADX  (see  Section  6.3)  and  correct  the  indicated  anomalies. 
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Revision  A 


As  noted  previously,  the  conventions  concerning  the  RSL  concepts  are 
documented  in  Section  3.0;  described  below  are  the  conventions  for  writing 
BETAs,  GAMMAs,  and  TESTs. 

7.1.1  Writing  Beta  and  Gamma  Models  for  Alphas 

The  required  processing  in  an  ALPHA  is  modeled  for  simulation  in  an 
executable  description,  either  a BETA  or  GAMMA  attribute.  These  executable 
descriptions  are  written  as  standard  PASCAL  procedures  with  the  following 
alterations: 

• The  user  does  not  provide  a procedure  heading  — this  is  done 
automatically  by  SIMGEN. 

• Special  statements  (peculiar  to  REVS)  are  used  to  access 
FILEs  --  these  are  translated  by  SIMGEN  into  legal  PASCAL 
statements. 

REVS  processes  the  executable  descriptions  to  produce  standard  PASCAL  pro- 
cedures for  incorporation  into  the  beta  or  gamma  simulator. 

All  of  the  normal  PASCAL  programming  features  and  facilities  are 
available,  except  that  all  data  that  is  not  strictly  local  to  a BETA  or 
GAMMA  must  be  declared  via  the  RSL  Data  Segment  (see  Section  3.1).  Com- 
munication between  BETAs  or  GAMMAs  of  several  ALPHAS  during  simulation  is 
via  the  DATA  described  in  the  Data  Segment.  Specifically,  a BETA  or  GAMMA 
communicates  via  the  DATA  INPUT  to  and  OUTPUT  from  the  ALPHA. 

DATA  specified  in  RSL  are  represented  in  simulations  as  variables  of 
the  same  names  and  of  the  type  assigned  by  the  RSL  attribute  TYPE.  Thus, 
reference  to  DATA  from  within  a BETA  or  GAMMA  is  via  the  RSL  name  of  the 
element  consistent  with  the  standard  PASCAL  reference  conventions. 

Accessing  FILES 

FILEs  consist  of  multiple  instances  of  the  DATA  CONTAINED  in  the 
FILE.  A series  of  statements  which  are  unique  to  REVS  and  serve  to  augment 
the  PASCAL  language  are  used  in  BETAs  and  GAMMAs  to  distinguish  between  the 
multiple  instances  in  FILEs  and  to  create  and  destroy  FILE  entries.  These 
file  access  statements,  described  below,  are  coded  in  the  executable 
description  as  though  they  were  PASCAL  statements;  they  are  translated  into 
executable  PASCAL  code  which  accesses  the  FILE  instances  during  simulation. 
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SELECT 


The  SELECT  statement  is  used  to  make  available  to  the  BETA  or  GAMMA 
the  contents  of  one  record  (instance)  In  a FILE.  In  BNF  (see  Appendix  A), 
the  syntax*  of  the  statement  Is: 

SELECT  |nextT||  REC0RD  FR0M  f11e-name 

[SUCH  THAT  (<Boolean  expression> )] 

If  FIRST  is  specified,  the  search  operation  begins  with  the  first 
record  in  the  FILE  (a  FILE  is  either  ordered  flrst-in-first-out  or  ORDERED 
by  DATA  CONTAINED  In  each  record  of  the  FILE).  If  NEXT  Is  specified  the 
search  begins  with  the  record  immediately  following  the  presently  selected 
record. 

If  a SUCH  THAT  criteria  Is  specified,  the  Boolean  expression  Is 
evaluated  using  the  DATA  from  the  current  Instance.  If  the  expression 
evaluates  FALSE,  the  next  Instance  Is  examined.  If  the  expression  evaluates 
TRUE,  the  predefined  local  DATA  Item  REC0RD_F0UND  Is  set  to  a Boolean  TRUE 
value,  the  contents  of  the  record  are  made  available  to  the  BETA/GAMMA  code, 
and  the  search  terminates. 

If  no  instance  is  found  that  meets  the  selection  criteria,  or  If  the 
FILE  is  empty,  REC0RD_F0UND  Is  set  to  Boolean  FALSE  and  the  search  Is 
terminated. 

The  selected  Instance  remains  selected  and  thus  Its  DATA  values  remain 
available  until  another  selection  Is  performed  on  the  FILE  or  the  net  Is 
terminated.  The  selection  remains  in  effect  even  though  the  processing  flow 
may  pass  from  one  ALPHA  to  another. 

CREATE 

The  CREATE  statement  adds  a new  record  to  a FILE.  The  syntax  of  the 
statement  Is: 

CREATE  file-name  RECORD 


♦The  syntax  of  the  special  statements  available  for  operating  on  FILES  In  a 
BETA  or  GAMMA  Is  summarized  In  Section  2 of  Appendix  G In  both  BNF  and 
syntax  diagram  form. 
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When  the  record  Is  created  It  is  automatically  selected  and  its  data  remain 
available  until  another  CREATE  or  SELECT  is  performed  on  the  FILE.  During 
the  creation  of  an  instance  all  DATA  items  ar-?  Initialized  to  their  stipu- 
lated values  from  the  INITIALJ/ALUE  attribute,  or  to  a default  value  if 
none  is  given.  After  a CREATE,  the  BETAs/GAMMAs  can  assign  new  values  to 
the  data  items  via  the  usual  PASCAL  assignment  statements. 

DESTROY 

The  DESTROY  statement  removes  the  currently  selected  record  from  a 
FILE.  The  syntax  of  the  statement  is: 

DESTROY  file-name  RECORD 

After  a DESTROY,  the  DATA  values  in  the  record  are  no  longer  available. 

The  DESTROY  performs  a de-selection  on  the  FILE;  thus,  the  assignment  of 
values  to  DATA  CONTAINED  in  the  FILE  is  meaningless  until  after  the  next 
selection. 

FOR  EACH 

The  FOR  EACH  statement  is  an  iterative  form  of  the  SELECT  statement. 

It  allows  a simple  means  of  applying  a common  operation  to  multiple  records 
In  a FILE.  The  FOR  EACH  header  specifies  the  FILE  and  the  criteria  (if 
any)  to  be  used  In  selecting  records.  An  ENDFOREACH  signals  the  end  of  the 
range  of  code  to  be  applied  to  each  instance  satisfying  the  evaluation 
criteria. 

FOR  EACH  file-name  RECORD  [SUCH  THAT  (<Boolean  expression>)]  DO 
<PASCAL  statement 
ENDFOREACH 

where  PASCAL  statement  is  defined  to  include  a file  access  statement  as  a 
legal  form. 

Each  Instance  Is  examined  in  turn,  beginning  with  the  first,  and  the 
logical  expression  evaluated  using  DATA  from  the  instance.  If  the  expression 
evaluates  to  true,  the  code  encompassed  by  the  DO  and  ENDFOREACH  is  executed 
using  the  instance  DATA.  If  no  instance  meets  the  criteria,  the  FOR  EACH 
is  null  and  the  embedded  code  is  not  executed.  FOR  EACH  structures  may  be  nested 
to  ten  deep.. 
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To  Illustrate  the  use  of  the  FOR  EACH  statement,  assume  that  an 
ALPHA  is  to  compute  X_ERROR_SUM  as  the  sum  of  all  instances  of  DATA  X_ERR0R 
CONTAINED  in  FILE  HISTORY.  The  following  GAMMA  would  accomplish  this  sum- 
mation. 

GAMMA: 

"BEGIN 

X_ERROR_SUM:  =0.0; 

FOR  EACH  HISTORY  RECORD  DO 

X_ERROR_SUM:  = X_ERROR_SUM  + XJERROR 
END FOR EACH; 

END;" 

The  same  operation  can  be  performed  using  SELECT  statements  as  shown 

bel ow: 

GAMMA: 

"BEGIN 

X_ERROR_SUM : =0.0; 

SELECT  FIRST  RECORD  FROM  HISTORY; 

WHILE  REC0RD_F0UND  DO  BEGIN 

X_ERROR_SUM : = X_ERROR_SUM  + X_ERR0R ; 

SELECT  NEXT  RECORD  FROM  HISTORY 
END 
END;" 

Simulating  Alpha  Entity  and  Message  Operations 

The  RSL  relationships  CREATES,  DESTROYS,  and  SETS  are  between  ALPHAS 
and  ENTITY_CLASSes  and  ENTITY JYPEs.  They  indicate  that  an  ALPHA  deter- 
mines the  existence  of  an  instance  in  an  ENTITY_CLASS  (CREATE  and  DESTROY) 
and  determines  its  specific  ENTITY_TYPE  (SETS).  The  relationship  FORMS 
between  an  ALPHA  and  a MESSAGE  indicates  that  the  ALPHA  designates  that  the 
MESSAGE  will  be  PASSED  through  the  appropriate  OUTPUT_INTERFACE  when  the 
Interface  is  encountered  subsequently  on  the  net. 

When  a simulator  is  generated,  the  code  to  perform  these  actions  is 
automatically  inserted  In  an  ALPHA'S  executable  description  (BETA  or  GAMMA). 

CREATES  and  SETS  are  performed  before  any  user  specified  code  In  the  BETA 
or  GAMMA  — all  CREATES  being  performed  first.  DESTROYS  and  FORMS  are  per- 
formed immediately  before  exiting  a BETA  or  GAMMA  after  any  user  specified 
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code  (if  a BETA  or  GAMMA  executable  description  is  omitted  from  the  ASSM,  a 
BETA  or  GAMMA  will  be  generated  containing  only  these  operations). 

Ir.  -esponse  to  a CREATES,  a new  entity  in  the  ENTITYJCLASS  will  be 
established.  All  DATA  items  ASSOCIATED  with  the  class  will  be  initialized 
to  their  INITIAL_VALUEs  or  to  default  values  if  no  INITIALJ/ALUEs  are 
specified.  After  a CREATES,  the  BETA/GAMMA  or  subsequent  ones  can  assign 
new  values  to  the  DATA.  The  CREATES  acts  as  an  entity  selection;  once  a 
new  entity  is  created,  it  is  selected  until  either  1)  another  ALPHA  CREATES 
a new  entity  In  the  ENTITY_CLASS,  2)  an  ALPHA  DESTROYS  the  newly  created 
entity,  3)  a SELECT  or  FOR  EACH  node  whose  subject  is  the  ENTITYjCLASS  or 
an  ENTITY_TYPE  which  COMPOSES  the  class  is  traversed  on  the  net,  or  4)  the 
net  Is  terminated. 

In  response  to  a DESTROYS,  the  currently  selected  entity  in  the 
ENTITYjCLASS  is  destroyed.  Since  the  DESTROYS  is  performed  at  the  end 
of  the  BETA  or  GAMMA,  DATA  ASSOCIATED  with  the  entity  becomes  unavailable 
upon  exiting  the  ALPHA  model.  The  DESTROYS  acts  as  a de-selection  on  the 
class  and  its  types. 

In  response  to  a SETS,  the  currently  selected  entity  in  the  ENTITY_ 
CLASS  COMPOSED  of  the  ENTITYJTYPE  will  be  assigned  the  specific  ENTITYJYPE. 
The  selected  entity  may  have  been  newly  created,  in  which  case  it  is 
assigned  a particular  ENTITYJTYPE  and  the  DATA  ASSOCIATED  with  the  type 
will  be  assigned  INITIALJ/ALUES. 

If  the  entity  is  not  newly  created  and  already  has  a type,  the  type 
will  be  changed  and  the  DATA  content  of  the  entity  will  be  changed  as 
follows:  DATA  ASSOCIATED  with  only  the  previous  type  will  be  removed;  DATA 
ASSOCIATED  with  only  the  new  type  will  be  assigned  INITIALJ/ALUES;  and 
values  of  DATA  ASSOCIATED  with  both  types  will  be  unaffected  and  remain 
available.  In  any  case  the  values  of  DATA  ASSOCIATED  with  the  ENTITYJCLASS 
will  remain  available  and  unchanged.  After  a CREATES,  a SETS  must  occur 
before  either  another  CREATES  occurs  on  the  class,  another  entity  is 
selected  from  the  ENTITYJCLASS,  or  the  RJIET  terminates. 

In  response  to  a FORMs,  conditions  are  established  such  that  the 
MESSAGE  will  be  PASSED  through  the  OUTPUTJNTERFACE  that  PASSES  the 
MESSAGE  when  the  processing  flow  reaches  the  interface.  DATA  which  MAKE 
the  MESSAGE  or  which  are  CONTAINED  in  FILES  making  the  MESSAGE  may  be 


assigned  values  before  or  after  the  FORMs  and  until  the  processing  flow 
reaches  the  OUTPUTJNTERFACE. 

7.1.2  Writing  Performance  Requirements  Tests 

As  described  in  the  RSL  Validation  Segment  (see  Section  3.4),  a 
PERFORMANCE_REQUIREMENT  has  an  attribute  TEST  which  defines  the  require- 
ment as  an  executable  test.  The  information  available  to  a TEST  is  all 
DATA  RECORDED  by  the  VALIDATION_POINTs  appearing  on  the  VALIDATION_PATHs 
CONSTRAINED  by  the  PERFORMANCE_REQUIREMENT.  When  generating  a gamma  simu- 
lator, REVS  will  also  automatically  generate  a simulation  post  processor 
corresponding  to  the  simulator;  only  the  TESTs  for  PERFORMANCE_REQUIREMENTs 
CONSTRAINIng  those  VALIDATION_PATHs  which  appear  in  the  simulator  are 
included  in  the  post  processor. 

TESTs  are  written  as  pass/fail  criteria.  The  executable  TEST  is 
translated  by  REVS  into  a Boolean  valued  PASCAL  function  whose  name  is  the 
name  of  the  PERFORMANCE_REQUIREMENT.  The  TEST  is  written  as  a standard  PASCAL 
function  with  the  following  alterations: 

• The  user  does  not  provide  a function  heading  - this  will  be 
done  automatically  by  SIMGEN. 

• Special  statements  (peculiar  to  REVS)  for  accessing  DATA  are 
used  - these  are  translated  by  SIMGEN  into  legal  PASCAL 
statements. 

RSL  elements  used  in  a TEST  (i.e.,  DATA)  are  referenced  directly  by  their 
RSL  names.  All  RSL  names  available  in  a oost  processor  are  automatically 
declared  by  REVS;  thus  the  only  declarations  which  should  appear  in  the 
TEST  are  those  for  variables,  constants  and  types  local  to  the  TEST. 

Conceptually,  each  time  during  simulation  that  the  processing  flow 
reaches  a VALIDATION_POINT  on  a net,  a RECORDING  is  generated  consisting 
of  all  DATA  RECORDED  by  the  VALIDATION_POINT.  A VALIDATION_POINT  can 
RECORD  a FILE;  In  which  case  DATA  is  extracted  for  each  record  in  the  FILE. 

The  same  DATA  and  FILES  may  be  RECORDED  by  many  VALIDATION_POINTs.  Thus, 

DATA  referenced  in  a TEST  must  be  uniquely  identified  by  VALIDATION_POINT, 
by  RECORDING,  and  by  record  in  a FILE;  a FILE  must  be  uniquely  identified 
by  VALIDATION_POINT  and  RECORDING. 

The  approach  used  to  establish  uniqueness  is  analogous  to  that  used 
in  the  remainder  of  RSL  for  DATA  and  FILEs  ASSOCIATED  with  entities  and 
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for  DATA  CONTAINED  In  FILES.  Identification  by  RECORDING  and  by  record  in 
a FILE  is  performed  by  selection.  Identification  by  VALIDATION_POINT  Is 
done  through  naming  conventions.  All  RSL  DATA  and  FILE  names  appearing  in 
the  TEST  are  prefixed  by  the  name  of  the  VALIDATION_POINT  which  RECORDED  the 
DATA  or  FILE  to  be  used.  The  two  names  are  separated  by  a decimal  point. 
(Thus,  to  refer  to  DATA  (or  FILE)  B RECORDED  by  VALIDATION_POINT  VI,  the 
identifier  VI. B is  used  in  the  TEST.) 

The  special  operators  for  identifying  a particular  RECORDING  are  the 
RETRIEVE  and  FOR  EACH.  These  operate  identically  to  the  SELECT  and  FOR  EACH 
on  FILES  written  in  BETAs  and  GAMMAs  (see  Section  7.1.1).  The  syntax  of 
the  RETRIEVE  is  shown  below  in  BNF  (see  Appendix  A).* 


RETRIEVE 


first)1 

NEXT  (, 


RECORDING  FOR  validation-point-name 


[SUCH  THAT  (<Boolean  expression>)] 


To  understand  the  operation  of  the  RECORDING  retrieval,  the  set  of 
RECORDINGS  generated  by  a VALIDATION_POINT  can  be  thought  of  as  an  ordered 
assemblage  with  a pointer  which  may  be  moved.  The  ordering  is  from  least 
to  greatest  on  simulated  time  of  generation  of  the  RECORDING.  The  RETRIEVE 
statement  first  repositions  the  pointer:  to  the  first  recording  for  RETRIEVE 
FIRST;  or  to  the  one  following  the  current  pointer  position  for  RETRIEVE 
NEXT.  The  condition  is  then  evaluated  using  the  DATA  in  the  RECORDING 
designated  by  the  pointer.  If  the  expression  evaluates  to  TRUE,  the  correct 
RECORDING  has  been  found.  Otherwise,  the  pointer  is  moved  to  the  next 
Instance  and  the  process  repeated.  If  the  condition  is  omitted,  the  RECORDING 
will  be  RETRIEVED  by  positioning  of  the  pointer  only. 


After  a RETRIEVE  operation,  the  predefined  Boolean  variable  RECORDING_ 
FOUND  will  have  the  value  TRUE  if  a RECORDING  which  meets  the  retrieval  was 
located;  otherwise  RECORD ING_F0UND  will  have  the  value  FALSE.  The  search 
does  not  go  end-around;  It  is  terminated  and  a value  FALSE  set  when  the  last 
RECORDING  Is  reached. 

After  a RECORDING  has  been  RETRIEVED,  all  references  to  DATA  and  FILEs 
in  the  RECORDING  are  assumed  to  refer  to  that  RECORDING.  The  RECORDING 


*The  syntax  of  the  special  statements  available  in  TESTs  is  summarized  In 
Section  3 of  Appendix  G in  both  BNF  and  syntax  diagram  form. 
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RETRIEVED  remains  available  until  the  next  RETRIEVE  or  FOR  EACH  on  the  same 
VALIDATION_POINT  is  encountered. 

The  syntax  for  the  FOR  EACH  on  VALIDATION_POINT  RECORDINGS  is  shown 

below: 

FOR  EACH  validation-point-name  RECORDING 

[SUCH  THAT  (<Boolean  expression:*)]  DO  <PASCAL  statement 
ENDFOREACH 


where  PASCAL  statement  is  defined  to  include  a special  TEST  data  access 
statement  as  a legal  form. 

The  FOR  EACH  on  RECORDINGS  has  the  same  meaning  as  the  FOR  EACH  on 
FILES  in  BETA/GAMMA  descriptions  (see  Section  7.1.1);  the  executable 
statements  encompassed  by  the  DO  and  ENDFOREACH  are  executed  for  each 
RECORDING  meeting  the  retrieval  criteria.  Again  the  RECORDINGS  are 
examined  in  the  order  of  their  recording  time.  If  the  condition  is  omitted, 
the  statements  will  be  executed  for  all  RECORDINGS  generated  by  the 
VALIDATION  POINT. 


Uniqueness  by  FILE  is  established  by  the  special  operators  SELECT 
and  FOR  EACH.  The  syntax  of  these  statements  is  shown  below. 

(first(  RECORD  FROM  val idation-point-name. file-name 


SELECT 


(NEXT  f1 


[SUCH  THAT  (<Boolean  expression:* )] 

FOR  EACH  val  idation-point-name  .file-name  RECORD 

[SUCH  THAT  (<Boolean  expression> )]  DO  <PASCAL  statement 
ENDFOREACH 


These  statements  have  the  same  interpretations  as  the  SELECT  and  FOR  EACH 
statements  on  FILES  in  BETAS  and  GAMMAs  (see  Section  7.1.1).  After  a SELECT, 
the  predefined  Boolean  variable  REC0RD_F0UND  will  have  the  value  TRUE 
if  a FILE  record  meeting  the  selection  criteria  was  located;  otherwise.  It 
will  have  the  value  FALSE. 


To  illustrate  the  use  of  these  statements,  assume  that  the  PERFORMANCE 
REQUIREMENT  X_ERROR_LIMIT  is  to  sum  the  X_ERR0R  RECORDED  by  the  VALIDATION_ 
POINT  VI  and  to  compare  this  to  a maximum  error.  X_ERR0R  is  contained  in 
FILE  HISTORY  which  is  also  RECORDED  by  VI.  The  following  TEST  would  specify 
this  requirement. 
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FOR  EACH  VI  RECORDING  DO 

FOR  EACH  VI. HISTORY  RECORD  DO 

X_ERROR_SUM : = X_ERROR_SUM  + VI .X_ERROR 
ENDfOREACH 
ENDFOREACH; 

X_ERROR_LIMIT:  = (X_ERROR_SUM  < X_ERROR_MAX) 

END;" 

Shown  below  is  the  equivalent  TEST  using  RETRIEVE  and  SELECT  state- 
ments instead  of  FOR  EACH  statements. 

TEST: 

"CONST  X_ERROR_MAX  = 50.0; 

VAR  X_ERROR_SUM:  REAL; 

BEGIN 

X_ERROR_SUM:  * 0; 

X_ERROR_LIMIT : = FALSE; 

RETRIEVE  FIRST  RECORDING  FOR  VI; 

WHILE  RECORD ING_FOUND  DO 
BEGIN 

SELECT  FIRST  RECORD  FROM  VI. HISTORY; 

WHILE  RECORDJOUND  DO 
BEGIN 

X_ERROR_SUM:  = X_ERROR_SUM  + VI .X_ERROR; 

SELECT  NEXT  RECORD  FROM  VI. HISTORY 
END; 

RETRIEVE  NEXT  RECORDING  FOR  VI 
END; 

IF  X_ERROR_SUM  > X_ERROR_MAX  THEN  X_ERROR_LIMIT:  « FALSE 
END;" 
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7.2  INTERFACING  A DRIVER 

In  order  to  generate  a simulator,  REVS  must  be  provided  with  a driver. 

This  driver  is  written  externally  to  REVS  in  PASCAL  and  Is  provided  to  the 
Simulation  Generation  (SIMGEN)  function  on  the  Simulation  Driver  Definition 
File  (SDF). 

REVS  provides  a standard  set  of  interface  routines  which  the  driver 
uses  to  communicate  with  the  simulated  data  processing  subsystem.  The 
interface  procedures  and  the  conventions  to  be  followed  in  writing  a driver 
are  described  In  the  following  sections. 

7.2.1  Representing  Subsystems 

The  data  processing  subsystem  has  interfaces  to  other  components  of 
the  system.  In  RSL,  INPUT_INTERFACEs  and  OUTPUTJNTERFACEs  CONNECT  the 
data  processing  subsystem  to  other  SUBSYSTEMS.  An  INPUT_INTERFACE  PASSES 
MESSAGES  to  the  data  processing  subsystem;  an  OUTPUT_INTERFACE  PASSES 
MESSAGES  from  the  data  processing  subsystem. 

Operation  of  a REVS  generated  simulator  is  based  on  the  driver  modeling 
these  SUBSYSTEMS  and  accepting  and  generating  the  specified  MESSAGES.  For 
each  SUBSYSTEM  specified  in  the  requirements  and  used  in  the  simulator,  there 
must  be  a corresponding  model  in  the  driver.  A SUBSYSTEM  model  must  be 
capable  of  either: 

1)  accenting  all  MESSAGES  PASSED  by  the  OUTPUTJNTERFACE  which 
CONNECTS  to  the  SUBSYSTEM; 

2)  generating  all  MESSAGES  PASSED  by  the  INPUTJNTERFACE  which 
CONNECTS  to  the  SUBSYSTEM;  or 

3)  performing  both  operations  if  the  SUBSYSTEM  CONNECTS  to  both 
an  INPUTJNTERFACE  and  ai  OUTPUTJNTERFACE. 

The  SUBSYSTEM  models  are  PASCAL  procedures.  The  procedure  names  are 
the  RSL  names  of  the  SUBSYSTEMS  being  modeled.  These  procedures  have  no 
calling  parameters  and  must  be  provided  on  the  SDF. 

7.2.2  Sending  Messages  to  the  Simulated  Data  Processing  Subsystem 

During  simulation,  an  R_NET  is  executed  when  a MESSAGE  which  is  PASSED 
by  an  INPUTJNTERFACE  becomes  available  at  the  interface.  A driver  SUB- 
SYSTEM model  causes  invocation  of  an  R_NET  by  posting  MESSAGES  for  a particular 
INPUTJNTERFACE  using  the  following  procedure  call: 
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EEPSTMES  (MESNAME,  MESTIME) 


where  MESNAME  is  the  RSL  name  of  the  MESSAGE  to  be  posted  at  time  MESTIME 
(real).  EEPSTMES  will  post  the  MESSAGE  for  that  INPUTJNTERFACE  which 
PASSES  the  MESSAGE.  The  R_NET  ENABLED  by  the  INPUTJNTERFACE  is  scheduled 
for  execution  at  MESTIME,  the  simulated  time  In  seconds  at  which  the  MESSAGE 
is  to  be  available  at  the  Interface.  A SUBSYSTEM  model  may  post  many 
MESSAGES  for  an  interface  — each  will  cause  a separate  invocation  of  the 
corresponding  R_NET. 

MESSAGES  may  be  MADE  by  FILES.  Before  posting  a MESSAGE  MADE  by  a 
FILE,  the  driver  must  create  the  FILE  records  using  the  following  procedure 
calls: 

EEBLDREC  (FILENAME)  - A record  for  the  FILE  is  created. 

EESAVREC  (FILENAME)  - The  newly  created  record  is  stored  into  the 

FILE  structure. 

The  FILENAME  is  the  RSL  name  of  the  FILE  being  created.  The  driver  sets 
the  values  of  DATA  CONTAINED  in  the  FILE  record  between  calls  to  EEBLDREC 
and  EESAVREC. 

7.2.3  Obtaining  Messages  from  the  Simulated  Data  Processing  Subsystem 

When  an  OUTPUT JNTERFACE  is  traversed  on  a net,  the  MESSAGE  FORMED 
for  that  interface  will  be  posted  for  communication  to  the  SUBSYSTEM 
CONNECTED  to  the  OUTPUT  JNTERFACE.  Each  posting  of  a MESSAGE  will  cause 
execution  of  the  corresponding  SUBSYSTEM  model  for  processing  of  the 
MESSAGE. 

In  the  simulator,  interfaces  are  represented  by  lists  containing 
the  posted  messages.  A SUBSYSTEM  model  obtains  access  to  messages  on  an 
interface  list  by  operations  analogous  to  the  BETA/GAMMA  SELECT  FIRST 
and  SELECT  NEXT  operations  on  FILES.  Only  one  message  per  Interface  list 
is  available  at  a time.  The  PASCAL  procedure  calls  described  below  are 
for  use  by  the  driver  In  accessing  messages;  in  each  case  the  Input 
parameter  INTNAME  Is  the  actual  RSL  name  of  the  OUTPUT  JNTERFACE. 

EEFSTMES  (INTNAME,  FFLAG)  - The  first  message  on  the  Interface 
list  Is  selected  and  made  available  for  reference. 

The  found  flag  FFLAG  is  set  to  TRUE  if  a message  is 
found  or  set  to  FALSE  if  a message  is  not  found. 


i 





7-16 


EENXTMES  (INTNAME,  DFLAG,  FFLAG)  - The  next  message  on  the  inter- 


face list  is  selected  and  made  available  for  reference. 

The  found  flag  FFLAG  is  set  to  TRUE  if  a message  is  found 
or  set  to  FALSE  if  a message  is  not  found.  If  the  input 
parameter  destroy  flag  DFLAG  is  set  TRUE,  the  previously 
selected  message  is  destroyed  before  selecting  the  next 
message. 

FILES  can  MAKE  MESSAGES.  Once  a MESSAGE  has  been  accessed,  individual 
records  in  a FILE  are  accessed  in  a manner  analogous  to  accessing  the  MESSAGE. 
The  following  procedure  calls  provide  FILE  access  for  the  driver: 

EEFSTREC  (FILENAM,  FFLAG)  - The  first  record  in  the  file  named  in 
the  FILENAM  parameter  is  selected  and  made  available  for 
reference.  The  found  flag  FFLAG  is  set  to  TRUE  if  a 
record  is  found  or  set  to  FALSE  if  a record  is  not  found. 

EENXTREC  (FILENAME,  FFLAG)  - The  next  record  in  the  named  file  is 
selected  and  made  available  for  reference.  The  found  flag 
FFLAG  is  set  TRUE  if  a record  is  found  or  set  to  FALSE  if 
a record  is  not  found. 

EEDSTREC  (FILENAME)  - The  currently  selected  record  in  the  file  is 
destroyed.  (A  record  must  have  been  previously  selected 
by  a call  to  either  EEFSTREC  or  EENXTRC.) 

Although  this  discussion  has  been  in  terms  of  OUTPUT_INTERFACEs,  these 
procedures  can  be  used  to  access  INPUT_INTERFACE  lists  if  this  is  required 
in  the  driver. 

7.2.4  Referencing  Data 

The  MESSAGES  PASSED  by  an  interface  are  MADE  by  DATA  and  by  FILES  which 
CONTAIN  DATA.  In  a simulator,  only  the  lowest  level  of  DATA  (pertinent  to 
the  type  of  simulation)  making  a MESSAGE  or  CONTAINED  in  a FILE  will  be 
represented.  A DATA  item  is  represented  by  a PASCAL  variable  of  the  same 
name  as  the  RSL  element  and  of  the  type  specified  by  the  value  of  RSL  attribute 
TYPE.  Thus,  the  driver  references  DATA  directly  using  the  RSL  name  of  the 
DATA.  The  variable  and  type  declarations  are  generated  automatically  by 
REVS. 

7.2.5  Scheduling  Driver  Events 

During  simulation,  a SUBSYSTEM  model  Is  scheduled  for  execution  whenever 
the  CONNECTIng  OUTPUTJNTERFACE  is  traversed  on  a net;  an  R_NET  is  scheduled  for 
execution  In  response  to  a SUBSYSTEM  model  posting  a MESSAGE  for  the 
enabling  INPUT_INTERFACE.  In  addition,  the  driver  may  execute  SUBSYSTEM 
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models  independently  of  the  R_NETs  by  scheduling  the  special  driver  pro- 
cedure SSEXOG.  SSEXOG  may  be  scheduled  to  execute  at  any  desired  simulation 
time.  This  allows  for  the  occurrence  of  internal  driver  events  which  are  not 
In  direct  response  to  MESSAGES  from  the  simulated  data  processing  subsystem. 

The  procedure  available  for  scheduling  driver  exogenous  events  is: 
PROCEDURE  EECAUSE  (SSEXOGSTR:EESTR;TIMEABS:REAL) 

where  SSEXOGSTR  is  a sixty  character  string  containing  the  word  SSEXOG  as 
the  first  six  characters  and  the  remaining  characters  are  blanks 
(EESTR=PAC KED  ARRAY  [1..60]  OF  CHAR). 

As  with  SUBSYSTEMS,  a procedure  named  SSEXOG  which  has  no  calling 
parameters  must  be  provided  in  the  driver  even  if  it  is  not  used. 

7.2.6  Obtaining  Simulation  Time 

The  current  simulated  time  is  available  to  the  driver  In  the  variable 
CLOCK_TIME;  this  Is  a pre-defined  DATA  of  TYPE  REAL  and  is  therefore  also 
available  to  the  R_NETs.  CLOCKJIME  should  be  treated  as  read  only;  it  is 
reset  from  a master  simulation  clock  just  prior  to  execution  of  an  R_NET,  a 
SUBSYSTEM  model  or  SSEXOG. 

7.2.7  Initializing  a Driver 

At  the  beginning  of  a simulator  execution  the  driver  procedure 
SSSTARTUP  will  be  invoked  to  allow  for  driver  initialization.  The  procedure 
SSSTARTUP,  which  has  no  calling  parameters,  must  be  provided  In  the  driver. 
SSSTARTUP  performs  any  Internal  driver  initialization  required  and,  at  a 
minimum,  posts  a message  to  the  data  processing  subsystem  to  Initiate  the 
simulation.  The  user  specified  start  time  and  end  time  are  available  to 
the  driver  as  the  values  of  the  real  data  Items  EESTARTTIME  and  EESTOPTIME, 
respectively. 

7.2.8  Organization  of  the  Simulation  Driver  Definition  File 

The  Simulation  Driver  Definition  File  (SDF)  contains  the  source  code 
for  the  driver  components  of  a simulator.  This  file  is  constructed  externally 
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to  REVS  and  is  organized  into  four  segments,  separated  by  the  character 
Each  segment  of  the  SDF  Is  inserted  into  its  proper  place  in  the  simulator 
during  execution  of  the  Simulation  Generation  Function. 

The  format  of  the  SDF  is: 

Constant  declarations 

$ 

Type  declarations 

$ 

Variable  declarations 

$ 

Model  procedures 

$ 

The  first  three  segments  contain  any  global  constant,  type,  and  variable 
declarations  required  by  the  driver.  Any  or  all  of  these  segments  may  be 
empty  but  the  segment  separators  ("$" ) must  be  present.  Also,  the  PASCAL 
keywords  CONST,  TYPE,  and  VAR  must  not^  be  stated.  The  fourth  segment  con- 
tains the  model  procedures  for  the  driver,  and  must  contain  a procedure 
SSSTARTUP  and  SSEXOG  and  a model  procedure  for  each  SUBSYSTEM  required  in 
the  simulation.  A model  procedure  must  have  the  same  name  as  the  SUBSYSTEM 
name  specified  in  RSL. 

7.2.9  Naming  Conventions 

The  RSL  names  for  elements  represented  in  the  simulator  (R_NETs,  SUBNETS, 
ALPHAS,  VAL IDAT I0N_P0 I NTs , DATA,  FILEs,  ENTITYJTYPEs,  ENTITY_CLASSes, 

MESSAGES,  SUBSYSTEMS,  INPUTJNTERFACEs , and  OUTPUTJNTERFACEs)  are  used 
directly  as  identifiers  in  the  simulator.  All  of  the  simulation  utilities 
are  named  with  a two  letter  prefix  of  EE. 


A driver  should  be  written  taking  care  not  to  duplicate  any  of  these 
names.  It  is  recommended  that  driver  identifiers  be  defined  using  the  two 
letter  prefix  SS. 


7-19 


7.3  GENERATING  A SIMULATOR  AND  POST  PROCESSOR  (SIMGEN  FUNCTION) 


The  generation  of  a simulator  and  post  processor  (for  a gamma  simu- 
lator) from  the  contents  of  the  ASSM  is  performed  automatically  by  Invoking 
the  REVS  Simulation  Generation  (SIMGEN)  function.  The  user  exercises 
control  over  the  scope  and  the  type  (beta  or  gamma)  of  simulator  and 
may  also  provide  an  identifying  name  for  the  simulator.  The  SIMGEN  commands 
to  exercise  these  control  are  presented  and  described  in  the  following 
subsection.  The  syntax  of  each  of  the  cormiands  is  presented  in  BNF  (see 
Appendix  A);  the  complete  syntax  is  summarized  in  Appendix  G in  both  BNF 
and  in  syntax  diagram  form. 

Several  types  of  diagnostics  may  be  issued  after  initiating  SIMGEN: 
SIMGEN  RCL  diagnostics,  data  base  analysis  diagnostics  (the  RADX  ANALYZE 
capability  described  in  Section  6.3  is  executed  by  SIMGEN),  and  SIMGEN 
translation  diagnostics.  The  SIMGEN  RCL  and  translation  diagnostics  are 
presented  and  explained  in  Appendix  G;  the  data  base  analysis  diagnostics 
are  documented  in  Appendix  F.  In  addition,  since  REVS  checks  only  the  special 
data  access  statements  in  the  BETA/GAMMA  and  TEST  attributes  for  correct- 
ness — not  the  PASCAL  statements,  the  PDL  2 or  PASCAL  compiler  may  issue 
error  diagnostics  when  compiling  the  simulator  and/or  post  processor.  The 
error  diagnostics  issued  by  these  compilers  are  explained  in  references  1 
and  2,  respectively. 

Only  one  simulator  and  corresponding  post  processor  may  be  generated, 
compiled  and  saved  during  an  execution  of  REVS.  See  Section  9 for  a description 
of  the  REVS  macros  related  to  the  generation  of  simulators  and  post  processors. 

7.3.1  Defining  the  Scope  of  the  Simulator 

REVS  does  not  require  a complete  set  of  requirements  to  be  specified 
In  the  ASSM  prior  to  simulation;  only  a portion  of  the  requirements  may  be 
simulated  (i.e.,  those  pertaining  to  a collection  of  R_NETS).  In  commanding 
SIMGEN,  the  user  specifies  the  particular  R_NETs  to  be  included  in  the  simu- 
lator. Based  on  these  R_NETs,  SIMGEN  will  include  only  those  RSL  elements 
required  to  support  simulation  of  the  processing  specified  by  these  nets. 
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The  user  designates  by  either  inclusion  or  exclusion  the  particular 
R_NETs  to  be  simulated.  In  both  cases  the  user  supplies  a list  of  the  RSL 
names  of  the  R NETS.  The  inclusion  statement  has  the  following  syntax: 


INCLUDE 


-Net-name 


Several  inclusion  statements  may  be  used. 


To  specify  the  contents  of  the  simulator  by  exclusion,  a statement 
with  the  syntax 


EXCLUDE  {R 


-Net-name 


is  entered.  Several  exclusion  statements  can  be  used;  the  resulting  simu- 
lator will  contain  all  R_NETs  specified  in  the  ASSM  except  those  appearing 
on  the  exclusion  lists.  A mixture  of  inclusion  and  exclusion  statements  is 
not  allowed. 


If  SIMGEN  is  to  use  all  R_NETs  in  the  ASSM  to  generate  a simulator 
the  following  command  is  entered: 

INCLUDE  ALL  [R_NETS] . 

If  this  form  of  Inclusion  statement  is  used,  the  include-list  form  described 
above  cannot  also  be  used. 


At  least  one  INCLUDE  or  EXCLUDE  statement  must  be  provided  to  SIMGEN 
in  order  to  generate  a simulator. 

7.3.2  Defining  the  Type  of  Simulator 

In  order  for  SIMGEN  to  generate  a simulator,  the  user  must  designate 
the  type,  either  beta  or  gamma,  of  simulation.  The  type  declaration  state- 
ment has  the  syntax 

F simulation]  XVD|r  rTO  (BETA 

[SIMULATOR J L (GAMMA ^ * 

At  least  one  simulation  type  declaration  must  be  provided;  if  multiple 
types  are  specified,  the  last  entered  will  be  used  by  SIMGEN. 
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7.3.3  Identifying  the  Simulator 

The  user  may  supply  an  identifier  for  a REVS  generated  simulator.  The 
identifying  name  is  entered  in  a SIMGEN  statement  using  the  following  syntax: 


'simulation 

_SIMULATOR 


ID 

IDENT 

identification). 


[IS]  identification-name. 


1 


If  multiple  identification  statements  are  provided  to  SIMGEN,  only  the  last 
name  entered  will  be  used.  The  identification  name  will  be  used  to  label 
the  output  of  the  simulator  and  the  output  of  the  corresponding  post  pro- 
cessor (gamma  simulation  only). 


7.4  EXECUTING  A SIMULATOR  (SIMXQT  FUNCTION) 


Simulators  generated  by  REVS  are  PASCAL  main  programs  which  are 
executed  as  independent  programs  outside  the  direct  control  of  REVS  using 
the  SIMRUN  macro  (see  Section  9.0  for  the  REVS  job  control  stream).  User 
inputs  to  a simulator  are  provided,  however,  through  the  REVS  Simulation 
Execution  (SIMXQT)  function. 

These  inputs  must  be  provided  through  SIMXQT  in  order  to  execute  a 
simulator.  For  any  execution  of  REVS,  only  one  set  of  inputs  can  be  pro- 
vided; if  SIMXQT  is  executed  more  than  once,  only  the  last  set  of  inputs 
will  be  routed  to  the  simulator. 

User  inputs  consist  of  simulation  start  and  end  times  and  a simulator 
run  identification.  These  inputs  are  described  below.  The  syntax  is 
presented  here  in  BNF  (see  Appendix  A),  and  again  in  Section  1 of  Appendix 
H in  both  BNF  and  syntax  diagram  form. 

Diagnostic  messages  may  be  issued  by  both  SIMXQT  and  by  an  executing 
simulator  program;  these  are  explained  in  Sections  2 and  3,  respectively, 
of  Appendix  H. 

7.4.1  Controlling  Simulation  Start  and  End  Times 

The  user  must,  at  a minimum,  supply  start  and  end  times  for  simulation. 

The  times  are  specified  as  real  numbers  in  units  of  seconds.  The  syntax 
for  these  SIMXQT  commands  are: 

[simulator"]  START  [T,HE1  ’ real -number. 

[1JmulAT0RN]  ™ tTIHEl  ■ real -number. 

Either  start  time  or  end  time  may  be  negative;  however,  end  time  must  be 
strictly  greater  than  start  time.  These  two  statements  may  be  entered  In 
either  order  but  both  must  be  present  for  simulator  execution.  If  multiple 
start  or  multiple  end  times  are  provided,  only  the  last  times  entered  will 
be  routed  to  the  simulator. 

In  the  simulator,  the  start  time  will  be  made  available  to  the  simulation 
driver  in  order  to  initiate  simulation  by  posting  messages  to  the  data  pro- 
cessing requirements  model.  During  simulation,  the  RSL  DATA  Item  CL0CK_ 

— 
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TIME  reflects  current  simulated  time.  When  the  value  of  CLOCK_TIME  equals 
or  exceeds  the  user  specified  end  time,  the  simulation  is  terminated. 

7.4.2  Identifying  the  Execution  of  the  Simulator 

The  user  may  supply  an  identification  for  any  execution  of  a REVS 
generated  simulator.  The  identifying  name  is  entered  in  a SIMXQT  control 
statement  using  the  following  syntax: 

FsTMiii’flTriR^l  RUN  \ IDENT  > [IS]  identification-name. 

[SIMULATOR  J . |IDENTIFICATI0n)1 

If  multiple  identifications  are  provided  to  SIMXQT  only  the  last  name 
entered  will  be  used.  The  identification  name  will  be  used  to  label  the 
output  of  the  simulator  and  the  output  of  the  corresponding  post  processor 
(gamma  simulation  only). 

7.4.3  Simulator  Output 

The  primary  output  of  a simulator  run  consists  of  an  RSL  element 
execution  trace  and  run  time  diagnostics.  Each  activation  of  an  R_NET 
will  be  documented  followed  by  the  names  of  the  nodes  reflecting  the  path 
which  was  executed  on  that  invocation  of  the  net.  Figure  7-2  shows  a 
sample  of  the  element  trace. 

Any  run-time  diagnostics  will  be  output  in  the  trace  at  the  point 
at  which  an  error  was  detected.  The  error  diagnostics  output  during  simu- 
lator execution  are  documented  In  Appendix  H. 

When  executing  a beta  simulator,  DATA  RECORDED  by  VALIDATION_POINTs 
will  be  automatically  output  to  a separate  print  file,  a simple  of  which 
Is  shown  in  Figure  7-3.  This  file  and  the  trace  file  will  be  printed  auto- 
matically by  the  REVS  job  control  stream  documented  in  Section  9. 

When  executing  a gamma  simulator,  a recording  file  Is  generated  for 
DATA  RECORDED  by  VALIDATION_POINTs . This  file  Is  processed  by  the  post 
processor  and,  since  It  is  not  a standard  print  file,  is  not  displayed  when 
executing  the  simulator. 
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7.5  EXECUTING  A POST  PROCESSOR  (SIMDA  FUNCTION) 


Simulation  post  processors  generated  by  REVS  are  PASCAL  main  programs 
which  are  executed  as  Independent  programs  outside  the  direct  control  of 
REVS  using  the  TE5TRUN  macro  (see  Section  9.0  for  the  REVS  job  control 
stream).  User  inputs  to  a post  processor  are  provided,  however,  through  the 
REVS  Simulation  Data  Analysis  (SIMDA)  function.  These  inputs  must  be  pro- 
vided through  SIMDA  In  order  to  execute  a post  processor.  For  any  execution 
of  REVS,  only  one  set  of  post  processor  inputs  can  be  provided;  if  SIMDA  is 
executed  more  than  once,  only  the  last  set  of  inputs  will  be  routed  to  the 
post  processor.  In  order  for  SIMDA  to  be  used  during  a REVS  execution,  a 
post  processor  must  have  previously  been  generated  by  SIMGEN  in  this  or  a 
prior  execution  of  REVS. 

7.5.1  Controlling  Performance  Requirement  Test  Selection 

User  Input  to  a post  processor  consists  of  the  designation  of  the 
PERFORMANCE_REQUIREMENTs  to  be  executed.  The  designated  PERF0RMANCE_ 
REQUIREMENTS  will  be  executed  to  evaluate  the  data  recorded  during  execu- 
tion of  the  corresponding  analytic  simulator. 


The  user  may  designate  that  either  all  or  a subset  of  the  PERFORMANCE 
REQUIREMENTS  be  executed.  To  test  the  simulation  results  against  all 
PERFORMANCE_REQUIREMENTs,  the  following  command  is  entered  Into  SIMDA: 

TFCT  fli  i T PERFORMANCE_REQU IREMENT s] 
itii  mll  LPERFOrmANCE_REQU IREMENT  J* 


To  select  a subset  cf  PERFORMANCE_REQUIREMENTs  for  execution,  the  user 
enters  a command  using  the  following  syntax: 

TrcT  [performance  REQUIREMENTS]  L.fnwn.„0  Qrlf  namo\n 

TEST  [pERFOrmANCE_REQUIREMENT  J (Performance-re9u1rement-nameJ1 • 

where  the  performance  requirements  names  are  the  RSL  names  of  the  Individual 
PERFORMANCE_REQUIREMENTs  to  be  executed.  The  user  can  designate  all  the 
names  In  a single  list  or  can  enter  this  type  of  command  several  times 
with  different  lists. 


If  the  list  of  requirements  Is  quite  long,  the  user  may  alternatively 
designate  those  PERFORMANCE__REQUIREMENTs  which  are  not  to  be  tested.  Entry 
of  the  statement 
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TpcT  All  fycfpt  [PERFORMANCE  REQUIREMENTS! 

1 MLL  tAU:n  |_PERFORMANCEllEQUIREMENT  J 

jperformance-requi rement-name j" . 

will  cause  all  PERFORMANCE_REQUIREMENTs  in  the  post  processor  to  be  executed 
except  those  designated  by  names  in  the  list.  Clearly  entry  of  more  than 
one  command  of  this  form  is  not  meaningful. 

SIMDA  will  diagnose  errors  in  the  user  input;  the  SIMDA  diagnostic 
messages  are  explained  in  Appendix  I.  Also  included  in  this  appendix  is 
the  syntax  of  SIMDA  RCL  in  both  BNF  and  syntax  diagram  form. 

7.5.2  Post  Processor  Output 

The  post  processor  output  consists  of  the  results  (pass/fail)  of  execu- 
tion of  the  PERFORMANCE_REQUIREMENT  TESTs  selected  by  the  user  and  any  post 
processor  execution  error  messages.  The  test  results  output  is  labeled  by 
simulator  and  simulation  execution  identification  and  by  time  arid  data  of 
both  the  generation  of  the  simulator  and  its  execution.  Shown  below  is 
sample  output  from  a post  processor. 

S I"UCAT  OR/tEST  CREATED  >-  .T 

RECORDING  HADE  ON  06/27/77  AT  09!5rt|5<*  WITH  ID  USEHS„HANUAL_E*  M CE» 

PERFORMANCE  REQUIREMENT  EXAMPue.PERFORMANCE.REQ  PASSED. 


Diagnostic  messages  output  by  a post  processor  are  documented  in  Appendix  I 
Output  is  written  to  a standard  print  file  which  is  printed  automatically  by 
the  job  control  stream  documented  in  Section  9. 


The  Requirements  Statement  Language  may  be  extended  or  changed  by 
the  definition,  modification,  and  deletion  of  element  types,  attributes, 
attribute  legal  values,  and  relationships.  The  remaining  primitives  of 


RSL,  the  Requirements  Network  STRUCTURES  and  the  validation  PATHS,  are 
only  extensible  in  that  the  element  types  which  can  occur  as  element  nodes 
on  them  are  extensible. 

Although  RSL  is  extensible,  the  only  parts  of  REVS  which  automatically 
adapt  to  these  extensions  are  the  RSL  and  RSLXTND  functions  and  the  RADX 
capabilities  for  subsetting  and  listing  requirements  (see  Sections  6.1  and 
6.2).  The  remaining  portions  of  the  REVS  tools  are  dependent  in  varying 
degrees  upon  the  existence  of  the  element  types,  attributes,  and  relation- 
ships described  in  the  RSL  Alpha,  Data,  Validation,  and  Requirements  Network 
Segments  (see  Sections  3.1  through  3.4).  The  only  concepts  within  these 
segments  which  can  be  freely  modified  or  deleteo  are  the  DATA  attributes 
MAXIMUM JALUE,  MINIMUMJALUE,  RESOLUTION,  and  UNITS,  and  the  VALIDATION_PATH 
attributes  MAXIMUM_TIME,  and  MINIMUM_TIME.  Extensions  may,  however,  be 
freely  made  within  the  Management  segment  (see  Section  3.5)  with  the  exception 
that  the  element  type  SYNONYM  and  the  relationship  EQUATES  have  special 
significance  and  should  never  be  altered. 

To  provide  management  control  over  changes  in  the  language  definition, 
a mechanism  has  been  provided  within  the  RSLXTND  function  which  can  be  used 
to  control  extensions  to  the  language.  This  control  mechanism  is  the  sub- 
ject of  Section  8.1.  Other  sections  below  detail  and  provide  examples 
illustrating  the  extensions  which  may  be  performed  on  the  language.  The 


RSLXTND  command  syntax  presented  is  expressed  in  the  extended  Backus-Naur 
Form  (BNF)  explained  In  Appendix  A.  The  complete  RSLXTND  syntax  from  which 
these  rules  were  extracted  Is  presented  in  Appendix  J,  In  both  BNF  and 
syntax  diagram  forms. 

It  should  be  noted  that  any  RSL  command  Is  also  a legal  RSLXTND 
command.  Also,  the  input  and  output  specifications  for  the  RSLXTND  function 
are  identical  with  those  given  for  the  RSL  function  in  Section  5.1. 
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8.1  CONTROLLING  LANGUAGE  EXTENSIONS 


The  RSL  extension  function  provides  commands  which  may  be  used  to 
establish  and  maintain  control  over  extensions  to  the  language.  These 
extension  controls  are  based  on  a two  level  system  of  permissions  which 
can  be  entered  into  an  ASSM  and  acquired  by  various  users.  The  highest 
level  of  permission,  control  permission,  denotes  the  permission  to  extend 
the  language  as  well  as  the  permission  to  establish  and  rescind  permissions. 
Extension  permission  is  subordinate  to  control  permission  and  denotes  the 
permission  to  extend  the  language  but  not  the  permission  to  establish  or 
rescind  permissions. 

The  use  of  controls  over  extension  to  the  language  is  optional.  If 
controls  are  not  in  use,  every  user  of  the  RSL  extension  function  (RSLXTND) 
has  control  permission  and  the  ASSM  is  said  to  be  uncontrolled.  If  controls 
are  in  use,  the  ASSM  Is  said  to  be  controlled  and  there  will  be  at  least 
one  control  permission  established  in  the  ASSM.  All  users  will  then  have 
only  the  level  of  permission  that  they  acquire  by  identifying  themselves 
(see  Section  8.! .3). 

There  are  four  types  of  extension  control  commands  used  to  identify 
users,  establish  control  permission,  establish  extension  permission,  and 
rescind  permissions.  These  commands  are  discussed  and  Illustrated  in 
separate  sections  below.  Each  command  syntax  contains  a name.  These  names 
are  treated  slightly  different  from  the  RSL  names.  They  have  only  58 
significant  characters  Instead  of  60  and  they  are  maintained  separately 
from  all  other  RSL  names  so  that  no  conflict  between  them  and  RSL  names 
can  ever  occur.  The  syntax  for  the  extension  control  commands  is: 

<extens1on  control  commands  : = 

IDENTIFICATION  name. 

| EXTENSI0N_PERMISSI0N  name. 

| C0NTR0L_PERM I SS ION  name. 

| RESCIND  PERMISSION  name. 

8.1.1  Establishing  Control  Permissions 

An  uncontrolled  ASSM  is  changed  into  a controlled  one  by  the  establish- 
ment of  a control  permission.  This  is  accomplished  by  stating  the  word 
C0NTR0L_PERMISSI0N  followed  by  a name.  For  example,  the  following  establishes 
a control  permission:  
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CONTROL_P ERM I SS I ON  CONTROL_ONE. 

A user  must  have  acquired  control  permission  before  he  can  establish 
a control  permission.  For  an  uncontrolled  ASSM  every  user  has  control 
permission  and  any  user  may  enter  the  first  control  permission,  converting 
the  ASSM  to  a controlled  one.  The  user  entering  the  first  control  permission 
retains  control  permission  until  he  exits  the  RSLXTND  function  or  identifies 
himself  (see  Section  8.1.3). 

All  control  permissions  in  an  ASSM  are  treated  as  equal.  Any  user  with 
control  permission  can  use  that  permission  to  establish  further  control  and 
extension  permissions  (see  Section  8.1.2),  to  rescind  permissions  (see 
Section  8.1.4),  and  to  extend  the  language  (see  Section  8.2). 

The  complete  syntax  for  establishing  a control  permission  is: 

extension  control  command>::= 

C0NTR0L_PERMISSI0N  name. 

8.1.2  Establishing  Extension  Permissions 

Once  a control  permission  has  been  entered  into  the  ASSM,  an  extension 
permission  may  be  entered  by  stating  the  word  EXTENSION_PERMISSION  followed 
by  a name.  For  example,  assuming  an  uncontrolled  ASSM  to  start,  the  following 
establishes  a control  permission  MAGIC  and  an  extension  permission  OPEN_SESAME. 

C0NTR0L_PERMISSI0N  MAGIC. 

EXTENSION_PERMISSION  OPENJSESAME. 

At  least  one  control  permission  must  exist  in  an  ASSM  before  any  ex- 
tension permission  may  be  entered.  As  long  as  at  least  one  control  permission 
exists  in  an  ASSM,  any  number  of  extension  permissions  may  be  entered  by  any- 
one who  has  acquired  control  permission. 

The  complete  syntax  for  establishing  an  extension  permission  is: 


extension  control  commands  : = 

EXTENSION_PERMISSION  name. 

8.1.3  Identifying  the  User 

If  an  ASSM  is  controlled,  a user  wishing  to  extend  the  language  or 
to  establish  or  rescind  permissions  must  first  acquire  the  appropriate 
level  of  permission.  Permission  is  acquired  by  stating  the  word  IDENTIFICA- 
TION followed  by  a name.  This  statement  Identifies  the  user  and  grants  him 
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the  permission  level  which  has  been  previously  associated  with  the  name 


specified.  For  example,  assume  that  in  a controlled  ASSM  control  permissions 
CP_1  and  CP_2  and  extension  permissions  EP_1 , EP_2,  and  EP_3  have  been 
established.  Either  of  the  following  statements  would  give  the  user  exten- 
sion permission,  allowing  him  to  extend  the  language  (see  Section  8.2): 

IDENTIFICATION  EP_1 . 

IDENTIFICATION  EP_2. 

IDENTIFICATION  EP_3. 

Either  of  the  following  statements  would  give  the  user  control  per- 
mission, allowing  him  to  establish  and  rescind  extension  and  control  per- 
missions as  well  as  extend  the  language. 

IDENTIFICATION  CM. 

IDENTIFICATION  CP_2. 

A user  retains  the  permission  level  he  has  acquired  until  he  either 
exits  the  RSLXTND  function  or  re-identifles  himself.  The  following  example 
shows  a user  first  acquiring  extension  permission  and  later  acquiring  no 
permission  since  there  is  no  permission  associated  with  N0_PER  in  our 
assumed  ASSM.  After  the  first  statement,  the  user  could  extend  the  language; 
after  the  second,  any  attempted  extensions  are  illegal. 

IDENTIFICATION  EP_2. 

‘ (language  extensions  legal) 

IDENTIFICATION  N0_PER. 

* (language  extensions  illegal) 

If  an  ASSM  is  uncontrolled,  all  users  have  implicit  control  permission 
and  Identification  should  not  be  used.  If  a user  does  identify  himself  and 
the  ASSM  is  uncontrolled  he  will  always  acquire  no  permission. 

The  syntax  for  identifying  a user  is: 

extension  control  commands  : = 

IDENTIFICATION  name. 


L 


8-5 


8.1.4  Rescinding  Permissions 


To  rescind  an  existing  permission,  the  words  RESCIND  PERMISSION, 
followed  by  a name  are  entered.  To  use  this  command,  the  user  must  have 
previously  acquired  control  permission.  For  example,  if  control  per- 
mission is  associated  with  both  KING  and  QUEEN  and  extension  permission 
with  COUNT  and  EARL,  the  following  sequence  will  remove  the  permissions 
associated  with  QUEEN,  COUNT,  and  EARL: 

IDENTIFICATION  KING. 

RESCIND  PERMISSION  QUEEN. 

RESCIND  PERMISSION  COUNT. 

RESCIND  PERMISSION  EARL. 

The  permission  associated  with  the  name  used  to  acquire  control  per- 
mission can  also  be  rescinded  but  this  rescission  does  not  take  effect 
until  the  next  IDENTIFICATION  coimand  or  the  exiting  of  the  RSLXTND  function. 
Thus  the  following  command  sequence  will  remove  all  permissions  In  the  above 
example,  resulting  in  an  uncontrolled  ASSM. 

IDENTIFICATION  QUEEN. 

RESCIND  PERMISSION  COUNT. 

RESCIND  PERMISSION  KING. 

RESCIND  PERMISSION  EARL. 

RESCIND  PERMISSION  QUEEN. 

Since  control  permission  is  necessary  to  rescind  other  permissions, 
the  last  remaining  control  permission  in  an  ASSM  cannot  be  rescinded  as 
long  as  there  is  at  least  one  extension  permission  outstanding.  Thus  the 
following  sequence  of  commands  is  invalid  since  an  extension  permission 
for  COUNT  still  exists: 

IDENTIFICATION  QUEEN. 

RESCIND  PERMISSION  KING. 

RESCIND  PERMISSION  EARL. 

RESCIND  PERMISSION  QUEEN. 

The  syntax  for  rescinding  a permission  is: 

extension  control  conmand>::  = 

RESCIND  PERMISSION  name. 
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8.2  DEFINING  NEW  RSL  CONCEPTS 

Using  the  RSLXTND  functions,  the  user  who  has  acquired  extension  or 
control  permission  may  define  new  RSL  concepts  in  the  realm  of  new  element 
types,  new  attributes,  and  new  relationships.  These  RSL  extension  defini- 
tions are  discussed  in  the  following  sections. 

8.2.1  Defining  a New  Element  Type 

The  syntax  for  defining  a new  element  type  is  that  of  a new  element 
type  definition,  which  in  its  simplest  form  is: 

[DEFINE]  ELEMENT_TYPE  element-type-name  comment. 

For  example,  the  following  defines  a new  element  type  named  NEW_0NE: 

DEFINE  ELEMENT_TYPE  NEW_0NE  (*EXAMPLE*) . 

The  word  DEFINE  may  optionally  precede  the  word  ELEMENT_TYPE  and  its 
use  is  recommended.  If  DEFINE  is  not  stated  and  the  element  type  name  is 
not  in  the  ASSM,  a new  element  type  definition  is  assumed;  however,  if 
DEFINE  is  not  stated  and  the  element  type  name  is  in  the  ASSM,  then  the 
assumption  is  that  the  existing  element  type  name  is  to  be  modified. 
Consequently,  it  is  always  safest  to  explicitly  use  the  word  DEFINE  when 
the  intent  is  to  define  a new  element  type.  The  following  definition  of 
NEW_0NE  is  thus  the  same  as  that  above  if  NEW_0NE  is  not  in  the  ASSM. 

ELEMENTJYPE  NEW_0NE  (*EXAMPLE*) . 

One  additional  sentence  type,  the  structure  applicability  declara- 
tion, optionally  preceded  by  the  word  INSERT,  may  be  used  to  complete  the 
new  element  type  definition.  This  declaration  has  two  forms  to  specify 
that  the  new  element  type  may  be  used  as  an  element  node  on  a net  STRUCTURE 
or  on  a validation  PATH.  The  form  of  the  structure  applicability  declara- 
tion is: 


STRUCTURE  APPLICABILITY 


As  an  example,  the  following  defines  three  new  element  types.  The 
first  one,  MY_TYPE,  may  be  used  as  an  element  node  on  an  R_NET  or  SUBNET 
STRUCTURE  and  on  a PATH.  The  second  one,  Y0UR_TYPE,  is  not  usable  on 
either  a STRUCTURE  or  a PATH.  The  third  one,  THEIR_TYPE,  is  usable  on  a 


STRUCTURE  but  not  on  a PATH. 
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DEFINE  ELEMENTJYPE  MY_TYPE  (*MY  OWN*). 

INSERT  STRUCTURE  APPLICABILITY  NET. 

INSERT  STRUCTURE  APPLICABILITY  PATH. 

DEFINE  ELEMENTJYPE  YOURJYPE  (*NOT  MINE*). 

DEFINE  ELEMENTJYPE  THEIR JYPE  (*NOT  GOOD  ON  PATHS*). 
STRUCTURE  APPLICABILITY  NET. 


The  user  who  wishes  to  define  new  element  types  should  be  cautioned 
that  the  new  element  types  defined  will  have  no  legal  attributes,  nor  will 
they  be  legal  subject  or  object  element  types  for  any  relationships  unless 
the  desired  attributes  and  relationships  are  modified  to  add  the  new 
element  types  to  their  applicable,  subject,  and  object  element  type  lists. 
The  method  of  making  these  modifications  is  presented  in  Sections  8.3.2 
and  8.3.3  for  attributes  and  relationships,  respectively. 

The  complete  syntax  for  a new  element  type  definition  is  as  follows: 


<new  element  type  def inition>: := 

[DEFINE]  ELEMENTJYPE  element-type-name  comment. 

^[INSERT]  structure  applicability  declaration^ 


structure  applicability  declarations : = 


STRUCTURE  APPLICABILITY 


8.2.2  Defining  a New  Attribute 

The  complete  definition  of  a new  attribute  consists  of  three  parts; 
a definition  of  a name  and  comment  for  the  new  attribute,  a declaration  of 
the  element  types  to  which  the  attribute  applies,  and  a declaration  of  the 
values  that  the  attribute  may  take  on.  The  definition  of  a name  and  comment 
must  precede  the  other  two  definition  parts  which  have  no  imposed  order. 

The  form  of  the  name  and  commet  definition  is  one  of  the  following: 

ATTRIBUTE  attribute-name  comment. 

DEFINE  ATTRIBUTE  attribute -name  comment. 


The  other  two  parts  of  a new  attribute  definition  are  both  forms  of 
the  attribute  definition  sentence,  optionally  preceded  by  the  word  INSERT. 
The  applicable  type  declaration  declares  the  element  types  to  which  the 
attribute  applies.  The  two  forms  of  the  applicable  type  declaration  are: 
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APPLICABLE  ELEMENTJYPE  <element  types>. 

APPLICABLE  « element  types>. 

There  are  three  forms  of  the  specification  of  <element  types>: 

ALL 

ALL  EXCEPT  jelement-type-namej^ 
jel ement-type-name 

The  first  form  means  that  elements  of  all  currently  defined  element  types 
except  SYNONYM  may  take  on  values  for  the  new  attributes.  The  second 
form  means  that  elements  of  all  currently  defined  element  types  except 
SYNONYM  and  those  listed  after  the  word  EXCEPT  may  take  on  values  for  the  new 
attribute.  The  third  form  means  that  only  elements  of  those  specific 
element  types  listed  may  take  on  values  for  the  new  attribute. 

The  syntax  for  a new  attribute  definition  allows  any  number  of 
applicable  type  declarations.  Multiple  applicable  type  declarations  are 
only  meaningful,  however,  if  all  of  them  are  in  the  third  form,  i.e.,  a 
list  of  element  type  names. 

The  values  that  the  new  attribute  may  assume  are  declared  in  one 
or  more  legal  value  declarations: 


VALUE 


NUMERIC 

TEXT 

NAMED 


.value-name 


[comment] . 


The  value  NUMERIC  means  that  any  signed  or  unsigned  integer  or  real  number 
as  defined  in  PASCAL  is  a legal  value  for  the  new  attribute  (see  Appendix  B). 
The  value  TEXT  means  that  any  string  of  characters  enclosed  within  double 
quotes  is  a legal  value.  The  value  NAMED  means  that  any  RSL  name  not  used 
in  another  context  in  the  ASSM  is  a legal  value.  The  value  name  form  means 
that  the  value  name  itself  is  a legal  value. 

Any  number  of  legal  value  declarations  may  be  included  in  a new  attribute 
definition.  Thus,  it  is  possible  to  state  that  a new  attribute  may  have  as 
many  legal  values  as  desired .including  any  combination  of  NUMERIC,  TEXT  and 
either  NAMED  or  any  number  of  specific  value  names.  Note  that  it  is  not  mean- 
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Ingful  to  have  legal  values  of  NAMED  and  one  or  more  specific  value  names  for 
an  attribute.  These  two  legal  value  forms  should  never  be  used  together. 


The  following  example  defines  a new  attribute  NEW_AT  which  can  apply 
to  any  element  of  type  ALPHA  or  SUBNET  and  which  can  take  on  any  NUMERIC 
or  TEXT  value: 

DEFINE  ATTRIBUTE  NEW_AT  (*C0MMENT  FOR  NEW  AT*). 

INSERT  APPLICABLE  ELEMENT_TYPE  ALPHA,  SUBNET. 

INSERT  VALUE  NUMERIC  (*ANY  NUMBER*). 

INSERT  VALUE  TEXT  (*ANY  TEXT  STRING*). 

As  shown  above,  more  than  one  legal  value  declaration  can  be  given. 
The  same  is  true  for  the  applicable  type  declaration  as  long  as  none  of 
them  uses  the  ALL  or  ALL  EXCEPT  form.  For  example,  the  following  is 
exactly  equivalent  to  the  attribute  definition  given  above: 

DEFINE  ATTRIBUTE  NEW_AT  (*C0MMENT  FOR  NEW_AT*) . 

APPLICABLE  ELEMENTJYPE  SUBNET. 

APPLICABLE  ALPHA. 

VALUE  TEXT  (*ANY  TEXT  STRING*). 

VALUE  NUMERIC  (*ANY  NUMBER*). 

The  following  example  defines  a new  attribute  A_0NE  with  legal  value 
VALJDNE , VAL_TW0,  and  NUMERIC  which  may  apply  to  elements  of  all  currently 
defined  element  types  except  DATA  (and  except  SYNONYM): 

ATTRIBUTE  A_0NE  (*A_0NE*). 

VALUE  VALJDNE. 

VALUE  NUMERIC. 

APPLICABLE  ALL  EXCEPT  DATA. 

VALUE  VAL_TW0. 

This  example  Illustrates  that  the  applicable  type  and  legal  value  declara- 
tions may  occur  In  any  order  and  may  even  be  intermixed. 

The  complete  syntax  for  a new  attribute  definition  is: 

<new  attribute  definitions := 

[DEFINE]  ATTRIBUTE  attribute-name  comment. 

{[INSERT]  attribute  definition  sentenced 
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<attribute  definition  sentences := 

<applicable  type  declaration> 

| <legal  value  declaration> 

applicable  type  declaration>:  : = 

APPLICABLE  [ELEMENT_TYPE]  <element  types>. 

<element  types>: := 

ALL 

| [ALL  EXCEPT]  jelement-type-namej" 

<legal  value  declaration>: := 


(NUMERIC 

VALUE  }TEXT 
VMLUt  ) NAMED 

(value-name’ 


[comment] , 


1 


8.2.3  Defining  a New  Relationship 

The  definition  of  a new  relationship  consists  of  four  parts;  a defini- 
tion of  a name  and  comment  for  the  relationship  followed  by  relation  defini- 
tion sentences  specifying  the  complementary  relationship  name,  the  element 
types  which  may  be  the  subjects  of  the  relationship,  and  the  element  types 
which  may  be  the  objects  of  the  relationship.  The  form  of  the  relationship 
name  and  comment  definition  is  the  following: 

[DEFINE]  | relationship^  relation-name 

• [("relation-optional-word")]  comment. 

This  part  of  the  definition  gives  a name  for  the  new  relationship,  called 
the  primary  relationship  name,  a comment,  and  may  give  a relation  optional 
word  which  may  be  used  in  RSL  commands  following  the  use  of  the  relation 
name  to  improve  readability. 

The  three  other  parts  of  the  new  relationship  definition  are  all  forms 
of  the  relation  definition  sentence,  optionally  preceded  by  the  word  INSERT. 
The  complementary  relation  declaration  declares  a name  for  the  complementary 
relationship  and  may  also  specify  a relation  optional  word  intended  to  be 
used  following  the  complementary  relation  name  in  RSL  commands  to  improve 
readability. 
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COMPLEMENTARY 


i RELATION  I' 
( RELATIONSHIP  f| 


relation-name 


[("relation-optional  -word")] . 


Notice  that  no  comment  is  allowed  in  the  complementary  relation  declaration 
while  one  is  required  for  the  primary  relationship  name.  Also,  the  primary 
and  complementary  relation  names  must  always  be  distinct  although  their 
relation  optional  words  have  no  such  restriction.  The  guidelines  followed 
in  the  core  relationships  for  RSL  (see  Section  3)  have  been  to  always  use 
the  present  tense,  third  person  singular  form  of  a verb  for  the  primary 
relationship  name,  and  to  use  the  past  tense,  third  person  singular  form 
of  the  same  verb  for  the  complementary  relationship  name.  Relation  optional 
words  were  used  whenever  their  use  would  improve  the  readability  and  natural- 
ness of  RSL. 

The  element  types  which  may  be  used  as  subjects  of  the  new  relationship 
are  defined  in  a subject  type  declaration: 

SUBJECT  [ELEMENT_TYPE]  <element  types>. 

There  are  three  forms  that  the  specification  of  the  <element  types>  may 
take: 

ALL 

ALL  EXCEPT  jel ement-type-name|^ 

jel  ement-type-name 

The  first  form  declares  that  elements  of  all  currently  defined  element  types, 
with  the  exception  of  SYNONYM,  may  be  used  as  subjects  of  the  new  relation- 
ship. The  second  form  declares  that  elements  of  all  currently  defined 
element  types  except  those  listed  (and  except  SYNONYM)  may  be  used  as  subjects 
of  the  new  relationship.  The  third  form  lists  specific  element  types  which 
may  be  used  as  subjects  of  the  new  relationship. 

The  element  types  which  may  be  used  as  objects  of  the  new  relationship 
are  defined  in  an  object  type  declaration: 

OBJECT  [ELEMENTJYPE]  <element  types>. 
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As  in  the  subject  type  declaration,  there  are  three  forms  of  the  <element 
types>  specification.  The  interpretation  of  these  forms  is  identical  except 
that  references  to  subject  element  types  should  be  read  as  references  to 
object  element  types. 

The  syntax  for  a new  relationship  definition  allows  any  number  of 
relation  definition  sentences  in  any  order.  For  a complete  and  valid  new 
relationship  definition  the  following  rules  should  be  adhered  to: 

• Exactly  one  complementary  relation  declaration  should  be  speci- 
fied. 

• At  least  one  subject  type  declaration  and  at  least  one  object 
type  declaration  should  be  specified. 

• Multiple  subject  or  object  type  declarations  should  be  speci- 
fied only  if  all  of  them  are  in  the  form  of  a list  of  element 
type  names. 

The  following  example  defines  a new  relationship  PR_1  with  relation 
optional  word  POW  and  complementary  relationship  CR_1  with  relation  optional 
word  COW.  The  relationship's  subject  and  object  element  types  are  all  the 
currently  defined  element  types  except  for  SYNONYM. 

DEFINE  RELATIONSHIP  PRJ  ("POW")  (*NEW  REL*). 

INSERT  COMPLEMENTARY  RELATIONSHIP  CR_L  ("COW"). 

INSERT  SUBJECT  ELEMENT_TYPE  ALL. 

INSERT  OBJECT  ELEMENTJYPE  ALL. 

Assume  that  the  only  currently  defined  element  types  are  ETJDNE, 

ET_T0W,  and  ET_THREE;  then  the  following  new  relationship  definition  is 
exactly  equivalent  to  the  example  above. 

RELATION  PRJ  ("POW")  (*NEW  REL*). 

OBJECT  ETJDNE,  ETJWO. 

SUBJECT  ALL. 

COMPLEMENTARY  RELATION  CRJ  ("COW"). 

OBJECT  ET_THREE. 

This  example  illustrates  that  the  three  declaration  parts  may  be  in  any 
order  and  that  multiple  subject  or  object  type  declarations  may  be  used. 

The  complete  syntax  for  defining  a new  relationship  is: 


<new  relation  definition>::= 

[DEFINE]  | RELATIONSHIP^  rel ation-name 

[("relation-optional  -word")]  comment. 

|[ INSERT]  <relation  definition  sentence>|Q 

<relation  definition  sentence>::= 

<complementary  relation  declaration> 

| <subject  type  declaration> 

| <object  type  declaration> 

<complementary  relation  declarations  : = 

COMPLEMENTARY  {relationship^  relation-name 

[("relation-optional  -word")] . 

<subject  type  declarations  : = 

SUBJECT  [ELEMENT_TYPE]  <element  types>. 

<object  type  declarations^ 

OBJECT  [ELEMENTJYPE]  <element  types>. 

<element  types>::= 

ALL 

| [ALL  EXCEPT]  jel ement-type-namej" 
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8.3  MODIFYING  RSL  CONCEPTS 

An  existing  element  type,  attribute,  or  relationship  definition  may 
be  modified  by  using  the  RSLXTND  commands  to  insert  new  information  into 
or  remove  information  from  the  definition.  The  user  wishing  to  modify  the 
standard  RSL  concepts  should,  however,  be  aware  of  the  restrictions  noted  in 
Section  8.0.  The  following  sections  describe  the  various  RSLXTND  commands 
used  to  perform  these  modifications  and  provide  examples  illustrating  their 
use. 

8.3.1  Modifying  an  Element  Type  Definition 

An  element  type  definition  may  be  modified  by  replacing  the  comment 
associated  with  the  element  type  or  by  inserting  or  removing  the  declara- 
tions allowing  its  use  as  an  element  node  on  a net  STRUCTURE  or  on  a PATH. 
The  element  type  modification  must  begin  with  a declaration  of  the  element 
type  which  is  to  be  modified: 

[MODIFY]  ELEMENT_TYPE  element-type-name  [comment]. 

The  word  MODIFY  is  optional  but  its  use  is  suggested.  If  MODIFY  is 
not  used,  the  RSLXTND  function  assumes  that  this  is  a new  element  type 
definition  if  the  element  type  name  is  not  already  in  the  ASSM.  The  comment 
is  also  optional;  if  a comment  is  provided  it  will  replace  the  existing 
comment  for  the  element  type,  otherwise  the  existing  comment  will  be 
retained.  The  following  two  examples  both  modify  an  assumed  element  type 
ET_ASSUMED.  The  first  one,  however,  does  not  change  the  definition  of 
ET_ASSUMED  while  the  second  one  gives  ET_ASSUMED  a new  comnent. 

MODIFY  ELEMENT_TYPE  ET_ASSUMED. 

MODIFY  ELEMENTJYPE  ET_ASSUMED  (*NEW  COMMENT*) . 

The  element  type  may  be  further  modified  by  inserting  or  removing 
structure  applicability  declarations.  The  syntax  for  inserting  a structure 
applicability  declaration  is: 

[INSERT]  STRUCTURE  APPLICABILITY  |p^H^- 

The  word  INSERT  is  optional  when  inserting  a structure  applicability 
declaration. 
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The  removal  of  a structure  applicability  declaration  requires  the  use 
of  the  word  REMOVE: 

REMOVE  STRUCTURE  APPLICABILITY 

For  example,  assume  that  the  following  definition  of  element  type 
TYPE_EX  has  been  made: 

DEFINE  ELEMENT_TYPE  TYPE_EX  (*EX  COMMENT*). 

INSERT  STRUCTURE  APPLICABILITY  NET. 

The  following  will  then  modify  the  definition  of  TYPE_EX  so  that  it  may  be 
used  as  an  element  node  on  a PATH  but  not  as  an  element  node  on  a STRUCTURE. 

MODIFY  ELEMENTJYPE  TYPE_EX. 

INSERT  STRUCTURE  APPLICABILITY  PATH. 

REMOVE  STRUCTURE  APPLICABILITY  NET. 


Note,  however,  that  if  one  or  more  elements  of  the  element  type  being 
modified  are  in  use  as  element  nodes  on  a STRUCTURE  or  PATH,  the  corresponding 
structure  applicability  declaration  (NET  or  PATH)  cannot  be  removed. 

The  complete  syntax  for  an  element  type  modification  is: 

<element  type  modifications := 

[MODIFY]  ELEMENT_TYPE  element-type-name  [comment]. 


{[p^MOVE  <structure  applicability  declaration;^ 


structure  applicability  declarations  : = 


STRUCTURE  APPLICABILITY 


8.3.2  Modifying  an  Attribute  Definition 

The  definition  of  an  attribute  consists  of  three  parts;  the  declara- 
tion of  a name  and  comment  for  the  attribute,  the  declaration  of  the 
applicable  element  types  for  the  attribute,  and  the  declaration  of  the 
values  that  the  attribute  may  assume.  Any  or  all  of  these  parts  may  be 
changed  in  order  to  modify  the  attribute  definition. 

Any  modification  of  an  attribute  definition  must  begin  with  a 
declaration  of  the  attribute  name  which  is  to  be  modified.  The  form  of 
this  declaration  Is: 
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[MODIFY]  ATTRIBUTE  attribute-name  [comment]. 

If  a comment  is  provided  in  this  declaration  it  will  replace  the  existing 
comment  for  the  attribute,  otherwise  the  existing  comment  will  be  retained. 

The  declaration  of  the  attribute  name  and  optional  corment  may  be 
followed  by  any  number  of  attribute  declaration  insertion  or  removal 
sentences.  These  sentences  perform  functions  which  are  the  subjects  of 
the  following  sections.  For  convenience  in  reference,  the  first  part  of 
the  syntax  of  the  attribute  modification  is  given  below.  The  sections 
following  will  detail  subordinate  parts  of  the  syntax  as  required. 

<attribute  modifications := 

[MODIFY]  ATTRIBUTE  attribute-name  [comment]. 

([INSERT]  attribute  definition  sentence^11 
\ applicable  type  declaration  removal > > 

v<legal  value  declaration  removal>  )0 

<attribute  definition  sentences := 

<applicable  type  declaration> 

<legal  value  declaration> 

8 . 3 . 2 . 1 Declaring  New  Applicable  Types  for  an  Attribute 

New  applicable  types  for  an  attribute  are  declared  by  giving  an 
applicable  type  declaration,  optionally  preceded  by  the  word  INSERT. 

[INSERT]  APPLICABLE  [ ELEMENT  JYPE]  <element  typess 

The  specification  of  <element  types>  is  one  of  the  forms: 


ALL 

ALL  EXCEPT  jelement-type-name 
jel ement-type-name 


K 


The  first  form  specifies  that  all  currently  defined  element  types  are  to 
be  added  as  applicable  element  types  (except  for  SYNONYM).  The  second 
form  specifies  that  all  currently  defined  element  types  except  those  listed 
(and  except  SYNONYM)  are  to  be  added  as  applicable  element  types.  The 
third  form  specifies  specific  element  types  which  are  to  be  added  as 
applicable  element  types.  If  the  attribute  already  has  one  or  more 


- 


•! 
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applicable  element  types  only  the  third  form  should  be  used  as  any  duplicate 
applicable  element  types  specified  will  result  in  errors. 

An  an  example  assume  that  element  types  ET_1 , ET_2,  ET_3,  and  ET_4  are 
currently  defined  but  only  ET_1  is  an  applicable  element  type  for  attribute 
AT_1 . The  following  would  establish  ET_2,  ET_3,  and  ET_4  as  additional 
applicable  element  types  for  attribute  AT_1 : 

MODIFY  ATTRIBUTE  AT_1 . 

INSERT  APPLICABLE  ELEMENT_TYPE  ET_2,  ET_3,  ET_4. 

The  same  result  would  be  accomplished  with  the  following: 

MODIFY  ATTRIBUTE  AT_1 . 

APPLICABLE  ET_4. 

APPLICABLE  ET_2,  ET_3. 

The  complete  syntax  for  declaring  new  applicable  types  for  an  attribute 
is: 

[INSERT]  applicable  type  declaration> 

<applicable  type  declaration:*:  : = 

APPLICABLE  [ELEMENT_TYPE]  <element  types>. 

<element  types>::= 

ALL 

| [ALL  EXCEPT]  jel ement-type-namej-" 

8. 3. 2. 2 Removing  Existing  Applicable  Types  for  A'n  Attribute 

One  or  more  existing  applicable  types  for  an  attribute  may  be  removed 
by  the  following: 

>1 


REMOVE  APPLICABLE  [ELEMENT  TYPE] 


IALL 

(element-type-name! 


The  form  ALL  means  that  all  element  types  which  are  currently  defined  as 
applicable  element  types  for  the  attribute  will  be  removed  as  applicable 
element  types.  The  result  will  be  an  attribute  defined  with  no  applicable 
element  types.  The  second  form  lists  specific  element  types  which  are  to 
be  removed  as  applicable  element  types  for  this  attribute.  An  error  will 
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be  detected  If  an  element  type  listed  is  not  an  applicable  element  type 
for  the  attribute. 


An  element  type  may  not  be  removed  as  an  applicable  element  type  for 
an  attribute  as  long  as  any  element  of  that  element  type  has  a value  for 
the  attribute.  The  attempted  removal  of  such  an  applicable  element  type 
will  be  diagnosed  as  an  error  and  rejected. 

As  an  example,  assume  that  attribute  MY_AT  has  been  defined  with 
applicable  element  types  MY_ET_1  and  MY_ET_2.  If  no  elements  of  type 
MYJETJ  or  MY_ET_2  exist  with  values  for  MY_AT  then  the  following  would 
remove  both  element  types  as  applicable  element  types  for  MY_AT: 

MODIFY  ATTRIBUTE  MY_AT. 

REMOVE  APPLICABLE  ELEMENTJYPE  ALL. 

The  same  result  would  be  achieved  by: 

MODIFY  ATTRIBUTE  MY_AT . 

REMOVE  APPLICABLE  MY_ET_2. 

REMOVE  APPLICABLE  MY  ET  1 . 


The  complete  syntax  for  removing  an  applicable  type  for  an  attribute 
is: 

applicable  type  declaration  removal>::  = 

(all 

REMOVE  APPLICABLE  [ELEMENTJYPE]  < , \n?  . 

f<element-type-nameM] 

8. 3. 2. 3 Declaring  New  Legal  Values  for  an  Attribute 

New  legal  values  for  an  attribute  are  declared  by  giving  a legal 
value  declaration,  optionally  preceded  by  the  word  INSERT. 

(NUMERIC  j1 

[INSERT]  VALUE  <™JD  > [comment]. 

(value-name!^ 

The  reader  is  referred  to  Section  8.2.2  for  a discussion  of  the  meanings  of 
the  words  NUMERIC,  TEXT,  NAMED  and  value  name. 

Any  number  of  legal  values  may  be  declared  for  an  attribute,  except 
that  an  attribute  should  never  have  legal  values  NAMED  and  one  or  more  value 


8-19 


i 


z 


names  at  the  same  time.  For  example,  assume  that  attribute  AT_0NE  has  been 
defined  with  legal  values  NUMERIC  and  NAMEjONE.  Then  the  following  would 
result  In  AT_0NE  having  legal  values  NUMERIC,  TEXT,  NAME_0NE,  and  NAME_TW0: 

MODIFY  ATTRIBUTE  AT_0NE. 

INSERT  VALUE  NAME_TWO  (*EXAMPLE*) . 

INSERT  VALUE  TEXT. 

The  complete  syntax  for  declaring  new  legal  values  for  an  attribute 
is: 


[INSERT]  <legal  value  declaration> 

<legal  value  declarations  : = 

(NUMERIC  i1 

VALUE)  NAMED  ( [comment]. 

' value-name  '-j 

8. 3. 2. 4 Removing  Existing  Legal  Values  for  an  Attribute 

An  existing  legal  value  for  an  attribute  may  be  removed  by  the 
following : 


REMOVE  VALUE 


(NUMERIC 

Jtext 

) NAMED 
'value-name 


Any  number  of  attribute  removal  declarations  may  be  given,  each  of 
which  removes  one  existing  legal  value  for  the  attribute  being  modified. 

No  legal  value  for  an  attribute  may,  however,  be  removed  as  long  as  an 
element  exists  with  a value  of  that  form  for  the  attribute. 

As  an  example,  assume  that  attribute  AT_MINE  is  defined  with  legal 
values  TEXT,  NAME_1 , NAME_2,  and  NUMERIC.  Then  the  following  would  remove 
NUMERIC  and  NAME_1  as  legal  values  for  AT_MINE. 

MODIFY  ATTRIBUTE  AT_MINE. 

REMOVE  VALUE  NAME_1 . 

REMOVE  VALUE  NUMERIC. 

The  following  would  remove  all  legal  values  for  AT_MINE  and  could  only  be 
accomplished  If  no  element  has  any  value  for  attribute  AT_MINE. 
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MODIFY  ATTRIBUTE  AT_MINE. 
REMOVE  VALUE  TEXT. 
REMOVE  VALUE  NAMEJ . 
REMOVE  VALUE  NUMERIC. 
REMOVE  VALUE  NAME  2. 


The  complete  syntax  for  removing  existing  legal  values  for  an  attribute 


<legal  value  declaration  removal>::= 

/ uiiMrnrr  \1 


REMOVE  VALUE 


NUMERIC 

TEXT 

NAMED 

value-name 


8.3.3  Modifying  a Relationship  Definition 

The  definition  of  a relationship  consists  of  four  parts:  (1)  the 
declaration  of  a primary  relationship  name,  comment,  and  optional  relation 
optional  word;  (2)  the  declaration  of  a complementary  relationship  name 
and  optional  relation  optional  word;  (3)  the  declaration  of  subject  element 
types  for  the  relationship;  and  (4)  the  declaration  of  object  element  types 
for  the  relationship.  Any  or  all  of  these  parts  may  be  changed  in  order  to 
modify  the  relationship  definition. 

Any  modification  of  a relationship  definition  must  begin  with  a 
declaration  of  the  relationship  name  which  is  to  be  modified.  The  primary 
relationship  name  must  be  used  in  this  declaration;  the  complementary 
relation  name  cannot  be  used.  The  form  of  the  declaration  is: 

[MODIFY]  {relatIONSHIP^  relatic"-name 

[ ("relation-optional -word")]  [conment] . 

If  a relation  optional  word  is  provided,  it  will  be  associated  with  the 
relation  name,  replacing  the  existing  relation  optional  word  if  one  existed. 
If  no  relation  optional  word  is  provided  any  existing  relation  optional 
word  for  the  relation  name  will  be  retained.  Also,  if  a comment  is  pro- 
vided, it  will  replace  the  existing  comment  for  the  relationship,  otherwise 
the  existing  comment  will  be  retained. 
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The  declaration  of  the  relation  name,  optional  relation  optional  word,  and 
conment  may  be  followed  by  any  number  of  relation  declaration  Insertion  or  removal 
sentences.  These  sentences  perform  the  functions  which  are  the  subjects  of 
the  following  sections. 

For  convenience  in  reference,  the  first  part  of  the  syntax  of  the 
relation  modification  is  given  below.  The  sections  following  will  detail 
subordinate  parts  of  tne  syntax  as  required: 

<relation  modifications := 

[MODIFY]  {RELATIONSHIP^  re1  ation-name 

[ ("relation-optional -word" )]  [comment] . 

[INSERT]  <relation  definition  sentence> 

<compl ementary  relation  declaration  removal 
<subject  type  declaration  removal > 

<object  type  declaration  removal > 

<relation  definition  sentences := 

<compl ementary  relation  declaration> 

| <subject  type  declaration> 

| <object  type  declaration> 

8. 3. 3.1  Declaring  a New  Complementary  Relation  Name  for  a Relationship 

A new  complementary  relation  name  for  a relationship  may  be  declared 
by  giving  a complementary  relation  declaration  optionally  preceded  by  the 
word  INSERT: 

[INSERT]  COMPLEMENTARY  | rIlaTIONSHIp)  relat1'on-name 
[("relation-optional  -word")] . 

As  discussed  in  Section  8.2.3,  the  definition  of  a relationship 
requires  that  exactly  one  complementary  relation  name  be  declared  for  each 
relationship.  Because  of  this,  the  only  time  that  a new  complementary 
relation  name  should  be  declared  for  an  existing  relationship  is  after  the 
existing  complementary  relation  name  has  been  removed  (see  Section  8. 3. 3. 2 
below).  Results  are  unpredictable  if  more  than  one  complementary  relation 
name  exists  for  a relationship. 

k., 
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As  an  example,  assume  that  relation  REL  exists  and  that  no  complementary 
relation  exists  for  REL.  The  following  will  then  define  CREL  with  relation 
optional  word  COPT  as  the  complementary  relation  name  for  REL. 

MODIFY  RELATIONSHIP  REL. 

INSERT  COMPLEMENTARY  RELATION  CREL  ("COPT"). 

With  the  same  assumptions,  the  following  would  declare  CREL_2  as  the 
complementary  relation  name  with  no  relation  optional  word. 

MODIFY  RELATION  REL. 

COMPLEMENTARY  RELATIONSHIP  CREL_2. 

The  complete  syntax  for  declaring  a new  complementary  relation  name 
for  a relation  is: 

[INSERT]  COMPLEMENTARY  j r^LATIONSH!? ^ re1ation-name 
[ ("relation-optional -word" )] . 


8. 3. 3. 2 Removing  a Complementary  Relation  Name  for  a Relationship 

The  complementary  relation  name  for  a relationship  may  be  removed  by 
giving  a complementary  relation  declaration  removal. 


REMOVE  COMPLEMENTARY 


(relation 

(RELATIONSHIP 


relation-name 


[ ("relation-optional -word" )] . 

The  complete  definition  of  a relationship  requires  that  a complementary 
relation  name  be  defined,  therefore  the  only  time  that  a complementary  rela- 
tion name  should  be  removed  is  when  it  is  to  be  replaced  by  a new  complementary 
relation  name  or  in  preparation  for  the  removal  of  the  relationship  definition. 

As  an  example  of  the  removal  of  a complementary  relation  name  assume 
that  relation  MY_REL  with  complementary  relation  name  MY_COMP_REL  is  defined. 
Then  the  following  will  remove  MY_COMP_REL. 

MODIFY  RELATION  MY_REL. 

REMOVE  COMPLEMENTARY  RELATION  MY_COMP_REL . 

If  there  is  a relation  optional  word  defined  for  the  complementary  relation 
name,  that  relation  optional  word  will  always  be  removed  along  with  the 
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complementary  relation  name,  regardless  of  whether  the  complementary  rela- 
tion declaration  removal  included  the  relation  optional  word. 

The  complete  syntax  for  the  removal  of  a complementary  relation  is: 
complementary  relation  declaration  removal>::= 


REMOVE  COMPLEMENTARY 


I RELATION  I 
l RELATIONSHIP) 


relation-name 


[("relation-optional -word" )] . 


8. 3. 3. 3 Declaring  New  Subject  Element  Types  for  a Relationship 

New  subject  element  types  for  a relationship  may  be  declared  by 
giving  a subject  type  declaration,  optionally  preceded  by  the  word  INSERT. 

[INSERT]  SUBJECT  [ELEMENT_TYPE]  <element  types>. 

The  specification  of  dement  types>  is  one  of  the  forms: 


ALL  EXCEPT  |element-type-name|^ 
|el ement-type-namej" 


The  first  form  specifies  that  all  currently  defined  element  types  are  to 
be  added  as  subject  element  types  (except  for  SYNONYM).  The  second  form 
specifies  that  all  currently  defined  element  types  except  those  listed 
(and  except  SYNONYM)  are  to  be  added  as  subject  element  types  for  the 
relation.  The  third  form  specifies  specific  element  types  which  are  to 
be  added  as  subject  element  types.  If  the  relationship  already  has  one 
or  more  subject  element  types  defined,  only  the  third  form  should  be  used 
since  any  duplicate  subject  element  types  specified  will  result  in  the 
detection  of  errors. 

As  an  example  assume  that  element  types  TYPE_1 , TYPE_2,  and  TYPE_3, 
are  currently  defined,  with  TYPE_3  defined  as  a subject  element  type  for 
relation  REL_1 . The  following  would  declare  that  TYPEJI  and  TYPE_2  are 
also  subject  element  types  for  relation  REL_1 : 

MODIFY  RELATIONSHIP  REL _1 . 

INSERT  SUBJECT  TYPE _2. 

SUBJECT  ELEMENT  TYPE  TYPE  1 . 
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The  complete  syntax  for  declaring  new  subject  element  types  for  a 
relationship  is: 


[INSERT]  <subject  type  declaration> 

<subject  type  declarations  : = 

SUBJECT  [ELEMENTJYPE]  <element  types>. 


<element  types>::= 

ALL 

| [ALL  EXCEPT  jel ement-type-namej^ 

8. 3. 3. 4 Removing  Subject  Element  Types  for  a Relationship 

One  or  more  existing  subject  element  types  for  a relation  may  be 
removed  with  a subject  type  declaration  removal: 


REMOVE  SUBJECT  [ELEMENTJYPE] 


ALL 

jel ement-type-name 


The  form  ALL,  or  the  lack  of  a specif ication  of  the  element  types  to  be 
retrieved, means  that  all  element  types  which  are  currently  defined  as 
subject  element  types  for  the  relation  will  be  removed  as  subject  element 
types.  The  result  will  be  a relationship  defined  with  no  subject  element 
types.  The  second  form  lists  specific  element  types  which  are  to  be 
removed  as  subject  element  types  for  the  relation.  It  is  an  error  to 
list  an  element  type  which  is  not  currently  a subject  element  type  for 
the  relation. 

A subject  element  type  for  a relation  may  only  be  removed  if  no 
element  of  that  type  is  the  subject  of  the  relation. 

As  an  example  assume  that  relation  PREL  is  defined  with  subject 
element  types  T J , T_2,  and  T_3.  The  following  will  leave  PREL  with  only 
T_2  as  a subject  element  type: 

MODIFY  RELATION  PREL. 

REMOVE  SUBJECT  ELEMENT  TYPE  T J , T 3. 


1 
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The  complete  syntax  for  the  removal  of  subject  element  types  for  a 
relation  is: 


<subject  type  declaration  removal > 
REMOVE  SUBJECT  [ELEMENT_TYPE] 


jel ement-type-nameji 


New  object  element  types  for  a relationship  may  be  declared  by  giving 
an  object  type  declaration,  optionally  preceded  oy  the  word  INSERT. 

[INSERT]  OBJECT  [ELEMENT_TYPE]  <element  types>. 

The  specification  of  <element  types>  is  one  of  the  forms: 


ALL 


ALL  EXCEPT  jel ement-type-name 
jel ement-type-name 


h 


The  first  form  specifies  that  all  currently  defined  element  types  are  to 
be  added  as  object  element  types  (except  SYNONYM).  The  second  form  speci- 
fies that  all  currently  defined  element  types  except  those  listed  (and 
except  SYNONYM)  are  to  be  added  as  object  element  types.  The  third  form 
lists  specific  element  types  which  are  to  be  added  as  object  element  types. 

If  the  relation  being  modified  already  has  one  or  more  object  element  types 
defined,  only  the  third  form  should  be  used.  Otherwise  the  duplicate 
declaration  of  object  element  types  will  result  in  the  detection  of  errors. 

As  an  example  assume  that  relation  REL_1  is  defined  with  object 
element  type  ET_1 . Also  assume  that  element  types  ET_2  and  ET_3  are  defined. 
Then  the  following  will  result  in  ET_1  , ET_2,  and  ET_3  being  object  element 
types  for  REL_1 : 

MODIFY  RELATIONSHIP  REL_1  . 

INSERT  OBJECT  ET_3. 

INSERT  OBJECT  ELEMENT  TYPE  ET  2. 
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The  complete  syntax  for  declaring  new  object  element  types  for  a 
relationship  is: 

[INSERT]  <object  type  declaration> 

<object  type  declarations := 

OBJECT  [ ELEMENT _TYPE]  <element  types>. 

<element  types>::= 

ALL 

( *n 
| [ALL  EXCEPT]  |el  ement-type-name^ 


8 . 3 . 3 . 6 Removing  Object  Element  Types  for  a Relationship 

One  or  more  object  element  types  for  a relation  may  be  removed  with 
an  object  type  declaration  removal: 


REMOVE  OBJECT  [ELEMENTJYPE] 


ALL 

I el  ement-type-name k 


The  form  ALL,  or  the  omission  of  the  specification  of  the  object  element 
types  to  be  removed,  means  that  all  element  types  currently  defined  as 
object  element  types  for  the  relation  will  be  removed  as  object  element 
types.  The  result  will  be  a relationship  with  no  object  element  types. 
The  second  form  lists  specific  element  types  which  are  to  be  removed  as 
object  element  types  for  the  relation.  An  error  will  be  detected  if  an 
element  type  is  listed  which  is  not  an  object  element  type  for  the  rela- 
tionship. 


An  element  type  may  not  be  removed  as  an  object  element  type  for  a 
relation  if  any  element  exists  which  is  the  object  of  that  relation. 


Assume  that  relationship  REL_NAME  is  defined  with  object  element 
types  TYPEJ , TYPE2,  and  TYPE_3.  The  following  would  remove  all  three 
as  object  element  types. 


MODIFY  RELATION  REL_NAME. 

REMOVE  OBJECT  ELEMENT  TYPE  ALL. 
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8.4  DELETING  RSL  CONCEPTS 


Any  of  the  existing  RSI.  element  types,  attributes,  or  relationships 
may  be  deleted  using  the  RSLXTND  function.  The  user  should  be  aware, 
however,  of  the  restrictions  noted  in  Section  8.0.  The  following  sections 
describe  the  RSLXTND  commands  used  to  perform  these  deletions  and  provide 
examples  illustrating  their  use. 

8.4.1  Deleting  an  Element  Type 

An  element  type  may  be  deleted  by  specifying  an  element  type  deletion: 
DELETE  ELEMENT_TYPE  element-type-name. 

An  element  type  may  only  be  deleted  if  it  is  not  in  use.  Any  of  the  follow- 
ing constitutes  a use  of  an  element  type  which  will  prevent  its  deletion: 

1.  An  element  of  the  element  type  exists.  The  element  must  be 
deleted  before  the  element  type  can  be  deleted  (see  Section 
5.1 .3). 

2.  The  element  type  is  an  applicable  element  type  for  an  attribute. 

The  attribute  must  be  modified  to  remove  the  element  type  as 

an  applicable  element  type  before  the  element  type  can  be 

deleted  (see  Section  8. 3. 2. 2). 

3.  The  element  type  is  a subject  or  object  element  type  for  a 
relationship.  The  relationship  must  be  modified  to  remove 
the  element  type  as  a subject/object  element  type  before  the 
element  type  can  be  deleted  (see  Sections  8. 3. 3. 4 and  8. 3. 3. 6). 

It  is,  however,  not  necessary  to  explicitly  remove  the  structure  applicability 
for  an  element  type  as  this  will  be  done  automatically  if  all  of  the  above 
conditions  are  met. 

As  an  example,  suppose  that  element  type  TYPE_0LD  is  defined  but  is 
not  used,  in  the  above  sense.  Then  the  following  will  delete  TYPEJDLD, 
including  its  net  or  path  structure  applicability  if  any  has  been  established: 

DELETE  ELEMENTJYPE  TYPE_0LD. 

If  TYPEJDLD  had  been,  for  example,  an  applicable  element  type  for  attribute 
AT_0NE  but  not  otherwise  in  use,  then  the  attribute  ATJDNE  would  first  have 
had  to  been  modified  to  remove  TYPEJDLD  as  an  applicable  element  type  before 
TYPEJDLD  could  be  deleted.  The  following  would  accomplish  this: 


| 

MODIFY  ATTRIBUTE  ATJDNE. 

REMOVE  APPLICABLE  ELEMENT_TYPE  TYPEJDLD . 

DELETE  ELEMENT_TYPE  TYPEJDLD . 

The  complete  syntax  for  deleting  an  element  type  is: 

<element  type  deletions : = 

DELETE  ELEMENT_TYPE  el ement- type- name. 

8.4.2  Deleting  an  Attribute 

An  attribute  is  deleted  by  an  attribute  deletion: 

DELETE  ATTRIBUTE  attribute -name. 

] 

The  only  necessary  condition  for  the  deletion  of  an  attribute  is  that  no 
element  may  exist  with  a value  for  the  attribute.  If  such  an  element 
exists,  the  attribute  instance  for  the  element  must  be  removed  or  the 
element  deleted  before  the  attribute  itself  may  be  deleted.  It  is  not, 
however,  necessary  to  remove  the  applicable  element  types  or  legal  values 
for  the  attribute.  These  will  be  automatically  removed  when  the  attribute 
is  deleted. 

As  an  example,  assume  that  attribute  ATJDNE  is  defined  as  follows: 

DEFINE  ATTRIBUTE  ATJDNE  (*EXAMPLE*) . 

INSERT  APPLICABLE  ELEMENT_TYPE  TYPEJ , TYPE_2. 

INSERT  VALUE  NUMERIC. 

INSERT  VALUE  TEXT  (*ANY  STRING  OF  CHARACTERS*). 

If  no  element  has  a value  for  ATJDNE  then  the  following  would  delete  ATJDNE. 

DELETE  ATTRIBUTE  ATJDNE. 

The  following  sequence  would  also  result  in  the  deletion  of  ATJDNE. 

MODIFY  ATTRIBUTE  ATJDNE  (*THIS  PART  UNNECESSARY*). 

REMOVE  APPLICABLE  TYPEJ,  TYPE_2. 

REMOVE  VALUE  TEXT. 

REMOVE  VALUE  NUMERIC. 

DELETE  ATTRIBUTE  ATJDNE. 

If  the  element  EL_EXAMPLE  had  a value  for  ATJDNE  the  removal  of  that 
attribute  instance  would  be  required  prior  to  the  deletion  of  the  attribute: 
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MODIFY  TYPEJ  EL_EXAMPLE 
REMOVE  ATONE. 

DELETE  ATTRIBUTE  AT_ONE. 

The  complete  syntax  for  the  deletion  of  an  attribute  definition  is: 

attribute  deletions : = 

DELETE  ATTRIBUTE  attribute-name. 

8.4.3  Deleting  a Relationship 

A relationship  definition  is  deleted  by  the  statement: 

DELETE  IrelaTIONSHIP^  relatlon-name 
[(''relation-optional  -word" )] . 

The  relation  name  used  in  this  statement  must  be  the  primary  relation  name; 
a complementary  relation  name  may  not  be  used.  As  shown  in  the  above  syntax, 
the  specification  of  the  relation  optional  word  is  optional.  Whether  it  is 
specified  or  not,  the  relation  optional  word  for  the  relationship  will  be 
removed  when  the  relationship  is  deleted. 

Only  one  circumstance  can  prevent  the  deletion  of  a relationship. 

That  circumstance  is  the  existence  of  an  instance  of  the  relationship  between 
elements  in  the  ASSM.  All  instances  of  a relationship  must  be  deleted  before 
a relationship  itself  may  be  deleted.  There  is,  however,  no  requirement  to 
remove  the  complementary  relation  name  or  the  subject  or  object  element 
types  before  deleting  a relationship.  These,  if  they  exist,  will  be  auto- 
matically removed  when  the  relationship  is  deleted. 

Assume  that  relationship  REL_EX  is  defined  as  follows: 

DEFINE  RELATION  REL_EX  ("0PT_W0RD" ) (MUST  AN  EXAMPLE*). 

INSERT  COMPLEMENTARY  RELATIONSHIP  C0MP_EX  ("C_0PT_W0RD") . 

INSERT  SUBJECT  ALL. 

INSERT  OBJECT  ALL. 

If  no  elements  are  related  by  REL_EX  then  the  relationship  may  be  deleted 
by: 

DELETE  RELATIONSHIP  REL  EX. 


L 
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Alternately,  the  relationship  could  be  modified  to  explicitly  remove  the 
complementary  relation  name  and  subject  and  object  element  types  before  the 
relation  was  deleted.  The  result  would  be  the  same. 


The  complete  syntax  for  deleting  a relationship  is: 
<relation  deletions : = 

DELETE  { RELATIONSHIP ^ relatlon-name 
[ ("relation-optional -word" )] . 


^ * 


REVS  operates  on  the  Control  Data  Corporation  (CDC)  7600  and  Texas 
Instruments  Advanced  Scientific  Computer  (ASC)  at  the  Ballistic  Missile 
Defense  Advanced  Technology  Center  (BMDATC)  Advanced  Research  Center  (ARC) 

In  Huntsville,  Alabama,  and  on  the  ASC  at  the  Naval  Research  Laboratory 
(NRL)  in  Washington,  D.C.  The  ARC  installations  of  REVS  operate  either 
from  card  input  (termed  off-line  mode)  or  interactively  (termed  on-line 
mode)  using  the  Data  Disc  Color  Graphics  (ANAGRAPH)  Display  System  Terminal. 
In  the  on-line  mode,  all  REVS  functions  are  available  to  the  user  and  may 
be  invoked  in  any  order.  In  the  off-line  mode,  all  functions  except 
RNETGEN  may  be  utilized  in  any  order.  The  NRL  installation  of  REvS  operates 
only  in  the  off-line  mode.  An  explanation  of  the  job  control  stream  required 
to  execute  REVS  on  each  of  these  computers  is  documented  in  the  following 
subsections. 
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REVS  is  invoked  as  a program  on  the  TI-ASC  through  the  use  of  the 
Job  Statement  Language  (JSL)  of  the  operating  system.  To  aid  the  user  In 
executing  REVS,  the  following  JSL  macros  have  been  defined: 

• REVSPREP  to  initialize  all  files 

• REVSXQT  to  execute  REVS 

t S1MRUN  to  execute  a REVS  generated  simulator 

• TESTRUN  to  execute  a REVS  generated  post  processor. 

Using  these  macros,  the  normal  job  setup  is  very  simple,  requiring  a JOB 
card  to  identify  the  job,  a LIMIT  card  to  specify  required  disk  and  CPU 
resources,  a MACASG  card  to  obtain  the  REVS  macros,  the  REVSPREP  JSL  macro 
call,  and  the  REVSXQT  macro  c-all  followed  by  REVS  RCL  and  RSL.  A job  set- 
up includes  macro  calls  to  SIMRUN  and  TESTRUN,  if,  respectively,  a simu- 
lator and/or  simulation  post  processor  are  to  be  executed.  Any  files  to 
be  referenced  with  an  ADDFILE  statement  within  REVS  must  be  provided  by 
the  user.  The  last  card  of  the  job  is  the  //  EOJ  card. 

The  JOB  and  LIMIT  cards  are  documented  in  the  TI-ASC  JSL  reference 
manual  [3].  The  MACASG  statement  is  installation  dependent  as  follows: 

• At  the  BMDATC  Advanced  Research  Center  (ARC): 

//  MACASG  M.USERCAT/TRW/ REVS/MACROS 

• At  the  Naval  Research  Laboratory  (NRL)': 

//  MACASG  M,AFFIL/IND/TRW/BERGP1/REVS/MACR0S 

Each  of  the  REVS  macros  is  described  in  the  following  subsections;  Section 
9.1.5  contains  sample  REVS  job  decks. 

9.1.1  REVSPREP  Macro 

The  REVSPREP  macro  provides  for  the  acquisition  of  all  necessary  files 
and  environmental  conditioning  for  use  of  REVS  on  the  TI-ASC.  The  parameters 
for  this  macro  are  defined  in  Table  9.1.  Defaults  for  the  parameters  are 
listed  in  the  table;  the  current  parameter  defaults  are  also  documented  in 
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Table  9.1  REVSPP.EP  Macro  Parameters 


PARAMETER 

FUNCTION 

DEFAULTS 

REVSVERS= 

version 

Specifies  the  disk  version  of  REVS 

+0 

REVSEFI D= 
tape  number 

Specifies  tape  number  of  REVS  baseline 
to  be  used 

Disk  version 
to  be  used 

ASSMEFID= 
tape  number 

Specifies  tape  number  of  ASSM  to  be 
staged  to  disk 

Disk  version 
to  be  used 

ASSMFILE= 
file  number 

Specifies  file  number  of  ASSM  on  tape 
if  ASSMEF1D  specified 

1 

ASSMBAND= 

bands 

Specifies  maximum  band  size  for  ASSM 
(4  pages/band) 

100 

ASSMVERS= 

version 

Specifies  the  disk  version  of  baseline 
ASSM 

+0 

SIMEFID= 
tape  number 

Specifies  tape  number  of  simulator  to 
be  used 

No  simulator 
loaded  from 
tape 

SIMGEN= 

lYESl 

\ NO  i 

Specifies  whether  SIMGEN  is  to  be 
executed  in  this  job  (applies  to  NRL 
only) 

NO 
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The  REVSPREP  must  be  used  once  and  only  once  per  job  and  must  precede 
calls  to  any  other  REVS  macros.  Any  number  of  REVS  executions  can  be 
specified  following  the  REVSPREP  card.  Normally,  only  one  execution  is 
required;  with  few  exceptions  (see  Section  7.0),  any  number  of  REVS  functions 
can  be  executed  in  any  order  within  one  step. 

9.1.2  REVSXQT  Macro 

The  REVSXQT  macro  invokes  execution  of  REVS  and  provides  all  control 
necessary  to  acquire  and  dispose  files  needed  during  the  REVS  step.  Table 

9.2  contains  an  explanation  of  the  macro  parameters  and  their  default 
values. 

9.1.3  SIMRUN  Macro 

This  JSL  macro  executes  a simulator  generated  by  the  SIMGEN  function 
of  REVS.  The  simulator  may  have  been  generated  in  a previous  REVSXQT  step, 
or  loaded  from  tape  by  the  REVSPREP  macro,  either  of  which  will  supply  the 
associated  files  needed.  Execution  of  the  SIMXQT  function  in  a previous 
REVSXQT  step  is  required  to  supply  necessary  simulator  input.  The  simu- 
lator may  be  saved  after  execution  if  recording  data  has  been  collected  for 
a simulation  post  processor  which  is  not  to  be  executed  in  this  job.  The 
SIMRUN  macro  parameters  are  defined  in  Table  9.3.  Parameters  on  the  PASCAL 
macro  PXQT  are  available  in  addition  to  those  shown  in  the  table. 

9.1.4  TESTRUN  Macro 

This  JSL  macro  executes  a simulation  post  processor  generated  by 
the  SIMGEN  function  of  REVS.  The  post  processor  may  have  been  generated  in 
a previous  REVSXQT  step,  or  loaded  from  tape  by  the  REVSPREP  macro.  The 
recording  data  base  used  by  the  post  processor  is  generated  by  execution  of 
a gamma  simulator,  and  is  saved  on  tape  with  a simulator  (a  null  data  base 
is  generated  if  the  simulator  is  saved  prior  to  execution  in  a SIMRUN  step). 
Execution  of  the  SIMDA  function  in  a previous  REVSXQT  step  is  required  to 
supply  necessary  post  processor  control  input.  Table  9.4  contains  an  ex- 
planation of  the  TESTRUN  macro  parameters  and  their  default  values.  In 
addition  to  those  shown  in  the  table,  parameters  of  the  PASCAL  macro  PXQT 
are  available. 
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Table  9.2  REVSXQT  Macro  Parameters 


PARAMETER 

FUNCTION 

DEFAULTS 

GO= 

access  name 

Specifies  program  file  to  be  executed 

REVSABS 

REVSIN= 
access  name 

Specifies  the  access  name  of  the  REVS 
input  file 

Unnamed  file 
of  cards 
immediately 
following  macro 

ADDMEM= 
memory  size 

Specifies  additional  memory  required  for 
file  buffers  (SIMGEN  requires  28K) 

12K 

STKSIZE= 

words 

Specifies  number  of  words  to  be  allocated 
to  the  stack 

10000 

HEAPSIZE= 

words 

Specifies  number  of  words  to  be  allocated 
for  heap 

10000 

0UTBAND= 
band  sizes 

Specifies  band  allocation  for  REVS. OUT 
file 

1/50/1 

DMPBAND" 
band  sizes 

Specifies  band  allocation  for  REVS.DMP 
debug  file 

1/10/1 

0PT= 

options 

Specifies  step  options 

(I) 

CPTIME= 

seconds 

Specifies  step  time  limit  in  seconds 

600 

CALCCMP= 

(YES  1 

NO 

| FOSYS  | 

(tape  number J 

Specifies  disposition  of  CALCOMP  plot  out- 
put. NO  means  suopress  tape  unconditional- 
ly. YES  means  produce  tape  only  if  plots 
are  actually  generated.  Plotting  requires 
tape  label  for  file  FT04F001  at  the  ARC. 

At  NRL,  plotting  is  performed  automatically. 
At  NRL,  FOSYS  indicates  that  the  online 
plotter  is  to  be  used.  At  NRL,  a tape 
number  can  be  specified  if  the  plot  tape  is 
to  be  saved  by  the  user. 

YES 

ASSMSAVE= 

1-1 

Specifies  disposition  of  ASSM  after  execu- 
tion. YES  means  save  on  tape  (requires 
label  for  file  FT02F001).  NO  means  leave 
on  disk  for  subsequent  cxection,  or  discard. 

NO 
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Table  9.2  REVSXQT  Macro  Parameters  (Continued) 


PARAMETER 

FUNCTION 

DEFAULTS 

REVSPNCH= 

" I 

(access  name) 

Specifies  disposition  of  punch  output. 

YES  means  punch  cards  if  RADX  has  been 
instructed  to  punch.  NO  means 
suppress  punching  even  if  RADX  punch 
statements  are  executed.  Specifying  an 
access  name  causes  the  punch  file  to  be 
retained  as  a job  local  file  with  the 
specified  access  name  for  subsequent 
user  disposition. 

YES 

$IMGEN= 

|YES| 

INO  / 

Specifies  whether  SIMGEN  will  be  used  in 
this  step.  YES  means  SIMGEN  may  be  execu- 
ted. NO  means  SIMGEN  will  not  be  executed 
and  therefore  no  capability  to  build  a simu- 
lator or  post  processor  is  to  be  provided. 

NO 

SIMSAVE= 

(YES| 

INO  / 

Specifies  whether  to  save  a generated  simu- 
lator on  tape.  YES  means  that  if  a simu- 
lator was  generated  it  will  be  saved  on 
tape  with  all  adjunct  files  required,  which 
includes  the  ASSM,  SDF  file  and  simulation 
post  processor,  if  any.  This  tape  can  be 
subsequently  reloaded  by  the  REVSPREP  macro 
for  execution  of  a simulator  or  simulation 
post  processor.  NO  means  don't  save  on  tape. 

NO 

REVSL0G= 

{KEEP! 

Specifies  whether  to  suppress  printing  of 
the  RCVSLOG  output.  KEEP  means  do  not 
print  but  leave  file  for  subsequent  user 
disposition  (for  use  by  interactive  users 
at  NRL),  * means  print  it. 

★ 

REVS0UT= 

fKE.EP) 

1 

Specifies  whether  to  suppress  printing  of 
REVS0U1  output.  KEEP  means  do  not  print 
but  leave  file  for  subsequent  user 
disposition  (for  use  by  interactive  users 
at  NRl.),  * means  print  it. 

* 

r 
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Table  9.3  SIMRUN  Macro  Parameters 


PARAMETER 

FUNCTION 

DEFAULTS 

STKSIZE= 

words 

Specifies  number  of  words  to  be  allocated 
to  the  run  time  stack. 

50C0 

HEAPSI ZE= 
words 

Specifies  number  of  words  to  be  allocated 
to  the  run  time  heap. 

5000 

ADDMEM® 
memory  size 

Specifies  additional  memory  required  for 
file  buffers. 

15000 

CPTIME® 

seconds 

Specifies  step  time  limit  In  seconds 

240 

SIMSAVE® 

lYESl 

INO  / 

Specifies  whether  to  save  simulator, 
simulation  post  processor,  recording  data 
base  and  associated  files  on  tape. 
Appropriate  only  for  gamma  simulations. 

NO 

Table  9.4  TESTRUN  Macro  Parameters 


PARAMETER 

FUNCTION 

DEFAULTS 

STKSIZE® 

words 

Specifies  number  of  words  to  be  allocated 
to  the  run  time  stack 

5000 

HEAPSIZE® 

words 

Specifies  number  of  words  to  be  allocated 
to  the  run  time  heap 

5000 

ADDMEM® 
memory  size 

Specifies  additional  memory  required  for 
file  buffx.'S 

15000 

CPTIME® 

seconds 

Specifies  step  time  limit  in  seconds 

240 
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9.1.5  Sample  REVS  TI-ASC  Job  Decks 

Figures  9-1  and  9-2  are  excerpts  from  sample  REVS  TI-ASC  job  decks. 
Figure  9-1  shows  a deck  setup  to  execute  REVS  using  three  ADDFILEs.  The 
other  sample,  Figure  9-2,  is  a deck  setup  to  generate  and  execute  a 
simulator. 
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//  JflB  BIN-IO-ERrF  ]S;D(PTL*Z,SM1TH 

//  limit  BANDs2on,MiN=*>0 

//  MaCASG  HACPBS.USc.PCAT/TRW/REvS/MACROS 

//  rEVSPRrP  ASSMEFID=630a 

//  RevSXQT  CPTlME=300n,HEApSI2E=30000 

RADX'. 

addFile  hier, 

ADd^ILE  LIsTSET, 

addFile  errors. 

STOP. 

//  start  acnm=hifr 

hieR  subsys_to_data  = subsystem  connected  Input ft interface# 

INPUT_INTERFACE  passes  MESSAGE, 
message  made  by  file, 
message  MADE  BY  data, 

FILE  CONTAINS  DATA, 

DATA  INCLUDES  DATA, 

• 

HIeR  et_a$sociates  = entity^type  associates  file* 

ENT  I T Y_T YPE  ASSOCIATES  DATA* 

file  contains  data, 

DATA  INCLUDES  DATA, 

//  Stop 

//  start  acnms-listset 

set  STD_DATA  5 FOUND, RECORD«FOUND,CLOCK_TIM£, 

• 

SET  of_enttty_related_data  a all  by  hier  eclass'. 
set  OF_MESsAGE^DaTA  = all  with  hier  MSG, 

SET  OF_FILE_NAMEs  S file. 

set  OF„DATa_CONTaINED..IN_FiLES  = ALL  BY  HIER  FILES, 

set  of_full y_cross_ref ereno  ed_require ments_ information  = ALL, 

set  data.with.enum  s SPECIFIED_DATA  with  type  S enumeration. 

• 


//  Stop 

//  Start  acnmserrors 
APPEND  all  NONE, 

LIST  OF_DATA_WITh  n0„S0URCE_0R_SINK, 

list  ofj>ata_kith_soijrce_but_no-sink. 


LIST  0F_EMpTY_NETW9RKS, 

LIST  0F„UN|)SED„NFTW0RK„ELEMF.NTS, 

APPEND  all  all, 

//  Stop 
//  F.OJ 

Figure  9-1  REVS  TI-ASC  Job  Deck  - Sample  1 
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//  JOB  JOBNAME* JOBNO* USEWNAHE 
//  LIMIT  BAND=200.MIN=20 
//  MACASG  MACROS* JSERC AT /TRW/kE VS/MACROS 
//  REVSPREP  ASSMVERS=*2 

//  REVSXOT  ADDMEM=28K.CPTIME=1200*HEAPSIZE=20000*SIMGEN=YES 
SImGeN, 

SIMULATION  TYPE  BETA, 

INCLUDE  ALL  R.NETS, 

SIMULATOR  IDENT  is  TRACKJkOOP, 

SImXqT. 

STaRT=0.0, 

ENd=S.O, 

run  id  IS  EXAMPLE  PCR  USERS.MANUAL, 

STOP. 

//  SIMRUN  0UTBAND=8/24/3 
//  TeSTRUN 

//  start  acnm=sdf 
f *sETS  Constant  declarations*) 

SScCiN  s»cC_IN 
SSrDrIN  a • rADAR  in 
SSrClKINsIrADAR^CLOCK  in 
S 

i*sets  Type  declarations*) 

SStRING  s PACKED  ARRAY  U..2S)  OF  CHAR) 

s 

(*sets  variable  declarations*) 

SSpOUND  I BOOLEANJ 
SSnUMR  I REAL) 

SSeED  I REAL) 

SST3C0UNT  I INTEGER) 

SST3CNTR  I INTEGER) 

SSflUTPUT  f TEXT) 

I 

(•sets  procedures*) 
procedure  SSEXOG) 

begin  (*  null  exogenous  event  procedure  *) 

END) 

procedure  ssstartup; 


end  t 

s 

//  stop 
//  EOJ 


Figure  9-2  REVS  TI-ASC  Job  Deck  - Sample  2 
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9.2  CDC  7600  JOB  CONTROL 

REVS  is  invoked  as  a series  of  programs  on  the  CDC  7600  through  the 
use  of  the  job  control  statements  of  the  operating  system.  The  following 
programs  emulating  the  JSL  macros  defined  for  REVS  on  the  TI-ASC  have  been 
defined: 

• REVSPRE  to  initialize  all  files 

• REVSXQT  to  execute  REVS 

• SIMRUN  to  execute  a REVS  generated  simulator 

• TESTRUN  to  execute  a REVS  generated  post  processor 

• SIMSAVE  to  save  a REVS  generated  simulator  and  post 
processor 

• SIMLOAD  to  reload  a REVS  generated  simulator  and  post 
processor. 

Using  these  programs,  the  normal  job  setup  can  be  very  simple,  requiring  a 
job  card  to  Identify  the  job  and  acquire  necessary  resources,  ATTACH  and 
LIBRARY  cards  to  obtain  the  library  of  REVS  programs,  a REVSPRE  card,  an 
EXIT(U)  card,  and  a REVSXQT  card  followed  by  a end-of-section  (7/8/9)  card 
and  REVS  RCL  and  RSL.  The  last  card  of  the  job  deck  is  an  end-of-lnformation 
(6/7/8/9)  card. 

A job  setup  may  include  additional  job  control  statements,  as  necessary, 
to  acquire  and  save  ASSM  files  and  to  provide  auxiliary  input  files,  such  as 
files  referenced  with  a-.  ADDFILE  statement  within  REVS.  The  job  setup  may 
also  include  SIMRUN  and  TESTRUN  cards  if,  respectively,  a simulator  or 
simulation  post  processor  are  to  be  executed.  A SIMSAVE  card  may  be  Included 
to  prepare  simulation  related  files  for  storage  on  tape  or  disk.  These  files 
may  then  be  made  available  In  a subsequent  job  by  a SIMLOAD  card. 

The  REVS  programs  are  described  in  the  following  subsections.  The 
required  ATTACH  and  LIBRARY  cards  are  as  follows: 

ATTACH ,REVSL I B .TRWREVS7600SYSTEM , ID=PTLREVS. 

LIBRARY, REVSLIB. 

••  >n«l  job  control  statements  are  documented  in  the  CDC  SCOPE  2.1  reference 
.a  4 Sample  REVS  job  decks  are  illustrated  in  Section  9.2.7. 


i 
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9.2.1  REVSPRE  Program 


The  REVSPRE  program  provides  for  the  acquisition  of  necessary  files 
and  environmental  conditioning  for  use  of  REVS  on  the  CDC  7600.  This 
includes  the  acquisition  of  an  ASSM  containing  the  predefined  element  types, 
attributes,  relationships,  and  elements  described  in  Section  3.  This  ASSM 
may  be  replaced  by  an  existing  ASSM  saved  as  a catalogued  file  by  placing 
the  following  two  control  cards  after  the  REVSPRE  card: 

RETURN  TAPE2 

GETPF,TAPE2,PERMFILENAME, ID=Y0URID. 

If  the  ASSM  is  on  tape  rather  than  on  a catalogued  file  then  the  GETPF  should 
be  replaced  by  an  appropriate  STAGE  or  REQUEST  card  as  described  in  [4], 
specifying  TAPE2  as  the  local  file  name. 

The  REVSPRE  must  be  used  once  and  only  once  per  job  and  must  precede 
calls  to  any  other  REVS  programs.  Any  number  of  REVS  executions  can  be 
specified  following  the  REVSPRE  card.  Normally,  only  one  execution  is 
required;  with  few  exceptions  (see  Section  7.0),  any  number  of  REVS  functions 
can  be  executed  in  any  order  within  one  step.  The  job  control  statement 
required  to  invoke  the  REVSPRE  program  is  simply  the  word  REVSPRE  followed  by 
a period;  there  are  no  parameters  defined. 

9.2.2  REVSXQT  Program 

The  REVSXQT  program  invokes  execution  of  REVS  and  controls  the  acquisi- 
tion and  disposal  of  files  needed  during  the  REVS  step.  To  insure  complete 
processing  by  REVS,  an  EXIT(U)  should  always  Immediately  precede  a REVSXQT  card. 
REVSXQT  provides  six  positional  parameters  representing  file  names  as  follows: 

REV  SXQT ( F I LE01 ,FILE02,FILE03,FILE04,FILE05,FILE06) 

The  parameters  and  their  default  values  are: 


File 

Default 

Interpretation 

FILE01 

INPUT 

Standard  REVS  input  file  (REVS. IN) 

FILE02 

OUTPUT 

Standard  REVS  log  file  (REVS.LOG) 

FILE03 

OUTPUT 

Standard  REVS  output  file  (REVS. OUT) 

FILE04 

OUTPUT 

DBCS  TAPE6  error  file  (DBCS.ERR) 

FILE05 

OUTPUT 

SIMGEN  debug  output  file  (REVS.DMP) 

FILE06 

PUNCH 

Standard  REVS  punch  file  (REVS. PUN) 
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All  files  with  the  default  name  of  OUTPUT  will  be  automatically  printed  by 
REVS  unless  the  file  names  are  overridden  ontheREVSXQT  card.  The  standard  REVS 
punch  file  will  also  be  automatically  punched.  If  any  of  these  file  names  are  over- 
ridden on  the  REVSXQT  cal  1 , the  user  assumes  responsibility  for  their  proper  disposition. 

The  REVSXQT  program  provides  for  the  automatic  compilation  of  a simula- 
tor and  post  processor  if  the  SIMGEN  function  is  invoked.  No  special  user 
action  is  required  to  accomplish  this.  REVSXQT  also  provides  for  the 
automatic  post-staging  of  any  plot  tape  if  plotting  was  requested  through 
RNETGEN  or  RADX.  The  local  file  name  for  the  plot  tape  is  TAPE  4 and  a 
tape  label  must  be  submitted  by  the  user. 

9.2.3  SIMRUN  Program 

The  SIMRUN  program  executes  a simulator  generated  by  the  SIMGEN 
function  of  REVS.  The  simulator  may  have  been  generated  in  a previous 
REVSXQT  step,  or  loaded  from  a tape  or  disk  file  by  the  SIMLOAD  program 
(see  Section  9.2.6),  either  of  which  will  supply  the  associated  files 
needed.  Execution  of  the  SIMXQT  function  in  a previous  REVSXQT  step  is 
required  to  supply  necessary  simulator  input.  The  SIMRUN  program  is 
invoked  by  a control  card  specifying  the  word  SIMRUN  followed  by  a period; 
there  are  no  parameters  defined.  Also,  to  insure  complete  processing  by 
REVS,  an  EXIT(U)  should  always  immediately  precede  a SIMRUN  card. 

9.2.4  TESTRUN  Program 

The  TESTRUN  program  executes  a simulation  post  processor  generated 
by  the  SIMGEN  function  of  REVS.  The  post  processor  may  have  been  generated 
in  a previous  REVSXQT  step,  or  loaded  from  a tape  or  disk  file  by  the 
SIMLOAD  program  (see  Section  9.2.6).  The  recording  data  base  used  by  the 
post  processor  is  generated  by  execution  of  a gamma  simulator,  and  is 
saved  along  with  a simulator  by  the  SIMSAVE  program  (see  Section  9.2.5). 

(A  null  data  base  Is  generated  if  the  simulator  is  saved  prior  to  execution 
in  a SIMRUN  step.)  Execution  of  the  SIMDA  function  in  a previous  REVSXQT 
step  is  required  to  supply  necessary  post  processor  control  input.  The 
TESTRUN  program  is  invoked  by  a control  card  specifying  the  word  TESTRUN 
followed  by  a period;  there  are  no  parameters  defined. 

9.2.5  SIMSAVE  Program 

The  SIMSAVE  program  consolidates  all  files  necessary  to  execute  a 
simulator  and  post  processor  generated  by  the  SIMGEN  function  of  REVS. 
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I These  files  are  combined  on  a local  file  named  SIMFILE.  This  file  can  then 

be  saved  on  disk  or  tape  by  using  the  appropriate  CATALOG,  REQUEST, 
or  STAGE  cards  as  described  In  [4].  The  files  combined  on  SIMFILE  include 
the  load  modules  for  the  simulator  and  post  processor  programs  as  well  as 
the  other  files  necessary  for  their  execution.  The  recording  data  base 
generated  by  execution  of  a gamma  simulator  is  Included  (a  null  data  base 
is  generated  If  the  simulator  is  saved  prior  to  execution  In  a SIMRUN  step). 
The  SIMSAVE  program  is  invoked  by  a control  card  specifying  the  word  SIMSAVE 
followed  by  a period;  no  optional  parameters  are  defined. 

9.2.6  SIMLOAD  Program 

The  SIMLOAD  program  reconstructs  REVS  simulator  and  post  processor 
files  previously  saved  by  the  SIMSAVE  program.  The  SIMLOAD  program  assumes 
that  these  files  are  available  on  a local  file  named  SIMFILE;  the  user  is 
responsible  for  supplying  the  necessary  ATTACH,  REQUEST,  or  STAGE  card  as 
described  in  [4]  to  obtain  this  local  file.  After  the  SIMLOAD  program  runs, 
the  loaded  simulator  and  post  processor  may  be  executed  by  the  SIMRUN  and 
TESTRUN  programs  after  the  required  SIMXQT  and  SIMDA  inputs  are  supplied  In 
a REVSXQT  step. 

9.2.7  Sample  REVS  CPC  7600  Job  Decks 

This  section  Illustrates  a number  of  sample  deck  setups  to  execute 
REVS  on  the  CDC  7600.  Some  familiarity  with  the  CDC  SCOPE  operating  system 
job  control  statements  as  defined  in  [4]  is  assumed. 

9. 2. 7.1  Nominal  Execution 

The  deck  setup  below  Illustrates  a minimal  job  starting  with  the 
predefined  ASSM  and  saving  no  resultant  ASSM. 

JOMNO«STmFZ*T77.  YOUR  NAME 

ATTACH, WE VSLTH«TRWRt  VS7600SYSTEM, ID  = PTLREVS, 

LIBRARY, WEVSLIS. 

HEVSPRE. 

EXIT.U. 

RFVSXilT. 


7/A/9  CARL) 
»EVS  INPUT  CAROS 

6/7/B/R  CAWD 


9. 2. 7. 2 Building  an  Initial  Data  Base 


The  deck  setup  below  illustrates  a job  which  constructs  and  saves  an 
ASSM  on  a catalogued  file.  To  save  the  same  ASSM  on  tape,  the  REQUEST  card 
would  be  replaced  by  the  appropriate  tape  REQUEST  or  STAGE  card  and  the 
CATALOG  card  removed. 

JORNO,STMFZ,T77.  YOUR  NAME 

ATTACH,REVSLIB,TRWREVS7600SYSTEM, ID=PTLREVS. 

LIBRARY  ♦REVSLIB. 

RFOUFST,TAPfcP,*PF. 

REVSPRE. 

EXIT , U. 

REVSXOT. 

CATALOG.TAPE2-.YOJRNAMEFORDA7  ABASE*  I D = YOUR  ID. 

7/9/9  CARD 
REVS  INPUT  CARDS 

6/7Z8/9  CARD 

9. 2. 7. 3 Updating  a Data  Base 

The  two  deck  setups  below  illustrate  jobs  which  update  an  existing 
data  residing  on  a catalogued  file.  The  first  deck  setup  does  not  save  the 
resultant  data  base;  the  second  deck  setup  does  save  the  updated  data  base. 
The  REQUEST,  GETPF,  and  CATALOG  cards  should  be  replaced  by  the  appropriate 
REQUEST  or  STAGE  cards  as  described  in  [4]  if  the  data  base  Is  maintained 
on  tape  ;ather  than  on  a disk  file. 

JORNO,STMFZ»T77.  YOUR  NAME 

ATTAfH,REVSLIR,TRWREVS7600SYSTEM, IO=PTLREVS. 

LIBRARY. BEVSLIB. 

REVSPRE. 

RETURN, TAPE2. 

GETPF » TAPE?, YOUR NAME  FORD AT ABASE, I D = YOUR  ID. 

EXIT .U , 

REVSXQT. 

7/8/9  CARD 
REVS  INPUT  CARDS 

6/ 7/8/9  CARD 


JO«Nn,STMFZ,T77.  YOUR  NAME 

ATT ACM, PE  VSLIP, TRWhEVS  780  0 SYSTEM, ID=PTLKEVS. 

LIBRARY, PEVSLIB. 

RF VSPRE  * 

RETURN, TAPE2. 

BFiJiJRST  ,TARFP,*PF. 

GFTPF,  TAPE?,  YOUpnA^E  FOROA TAp A , {()  = YOUkID. 

FXIT.U. 

RFVSXQT. 

CAT  At  OG,TAPr  /.  YO.IBnAmee  ORDA  I A r)  A S r.  , I D = YOUP  ID. 

7/M/9  CARD 
REVS  input  cards 

8/7/h/R  CARD 
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9. 2. 7. 4 Executing  and  Saving  a Simulator/Post  Processor 

The  deck  setup  below  constructs,  executes,  and  saves  a simulator  and 
post  processor.  The  files  catalogued  on  the  disk  file  will  include  the 
recording  data  base  generated  by  the  execution  of  the  simulator  since  the 
SIMRUN  precedes  the  SIMSAVE.  To  save  the  simulator  files  on  tape  rather 
than  on  a catalogued  file,  the  REQUEST  card  should  be  replaced  by  an 
appropriate  tape  REQUEST  or  STAGE  card  as  described  in  [4],  and  the  CATALOG 
card  removed. 

JO&Nn,5TMK7,  T 77.  YOUR  NAME. 

AT TACH.kFVSL I T RWHt  VS /hOOSYSTEM, IO  = PTLREVb , 

l IMRAPY.Kt.VSL  IH. 

REVSRRE . 

RE  TURN, r uPE  ? , 

Of  THE  , TARc  Y O U K A " E FORU'*  T A 4 A .->E.  . 1 1.»  = YOUK I !). 

EXT  T.U. 

REVSVdT . 

EX  I T .11. 

STMRIIN. 

WFOUEST  .SIMFTLw.  *PE  . 

S T M S A V r . 

CATALOG.  SI  vie  II.  t , ruuf  MAMEf-  ORSI^ULAT  ORE  I L t » I 0 = YO JR  1 0 . 

TEST  RUN . 

7/k/R  CAR,j 
RfcVS  IMRUT  CJ.iRDS 

S/7/0/9  CAkO 

9. 2. 7. 5 Loading  and  Executing  a Simulator 

The  deck  setup  below  illustrates  a job  which  loads  a previously  saved 
simulator  and  executes  it.  If  the  simulator  had  been  saved  on  tape  rather 
than  on  a catalogued  file,  then  the  ATTACH  card  would  be  replaced  by  the 
appropriate  REQUEST  or  STAGE  card  as  described  in  [4]. 

JfMHn,STMF/,T  77.  YOUR  N A ME 

ATTAEH.wFVSL  M.T  VWRE  VS7o(IOSYSU  R.  Jr  = RTLRE.VS. 

L THRftRY  . REVS!  I -I. 

RE  V SrR t . 

ATTACH,  SI  ME  II  E « Y 'TURN  « Xr.r  ORS  l MOL  A TORE  ILt  . 10  = YOUR  10. 

SIML.OAI'. 

EX  I T.U. 

RFVSvoT . 

E X IT .U. 

S I MWI  IN  , 

7/-*/o  r aki) 

revs  inrut  capos 

S/7/M/R  CAk|, 
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10.0  INSTALLATION  DEPENDENCIES 

This  section  describes  those  portions  of  REVS,  exclusive  of  the  job  con- 
trol streams  described  In  Section  9,  which  are  Installation  dependent.  The 
dependencies  for  each  installation  of  REVS  are  discussed  in  separate  sub- 
sections. 
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10.1  TI-ASC  DEPENDENCIES 


This  section  describes  the  REVS  dependencies  as  they  apply  to  the 
installations  of  REVS  on  the  TI-ASC,  both  at  the  Naval  Research  Laboratory 
(NRL)  in  Washington,  D.C.,  and  at  the  Ballistic  Missile  Defense  Advanced 
Technology  Center  (BMDATC)  Advanced  Research  Center  (ARC)  in  Huntsville, 
Alabama. 


10.1.1  Character  Set 


The  ASC  installation  of  REVS  uses  the  standard  EBCDIC  character  set. 

All  characters  will  print  as  shown  in  this  document. 

10.1.2  CALCOMP  Plotting  Symbols 

The  symbols  plotted  by  the  ASC  installations  of  REVS  agree  with  those 
shown  In  Figure  5-2. 

10.1.3  Operating  Modes 

The  on-line  operating  mode  is  available  In  the  ARC  ASC  Installation 
but  not  in  the  NRL  ASC  installation.  There  is  no  restriction  on  the  number 
of  times  a user  may  use  the  on-line  mode  in  the  ARC  ASC  installation. 

10.1.4  TI-PDL  2 Compiler 

Simulators  and  post  processors  generated  by  ASC  Installations  of  REVS 
are  compiled  using  the  TI-PDL  2 compiler  described  in  Volume  1 of  [1].  No 
restrictions  exist  beyond  those  defined  In  that  volume. 

10.1.5  Linkage  Editor 

The  standard  ASC  linkage  editor  [5]  is  used  to  link-edit  the  simulators 
and  post  processors  generated  by  ASC  installations  of  REVS.  To  Insure  proper 
link-editing, elements  of  the  following  element  types,  when  used  in  simulating 
requirements,  must  be  unique  in  the  first  eight  characters:  ALPHA, 
PERFORMANCE_REQUIREMENT,  R NET,  SUBNET,  SUBSYSTEM,  VALIDATION_POINT. 


10.2  CDC  7600  DEPENDENCIES 
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This  section  describes  the  REVS  dependencies  as  they  apply  to  the 
REVS  installation  on  the  CDC  7600  at  the  Ballistic  Missile  Defense  Advanced 
Technology  Center  (BMDATC)  Advanced  Research  Center  (ARC)  in  Huntsville, 
Alabama. 

10.2.1  Character  Set 

The  ARC  CDC  7600  installation  of  REVS  uses  the  standard  BCD  character 
set.  All  characters  will  print  as  shown  in  this  document  with  the  following 


exceptions: 

CDC  ASCII 

Hollerith 

ASCII 

Character 

Graphic  Graphic 

Punch  (026) 

Punch  (029) 

double  quote 

t 

8-4 

8-7 

underscore 

-> 

0-8-5 

0-8-5 

vertical  bar 

] T 

0-8-2 

11-8-2 

up-arrow 

♦ ' 

11-8-5 

8-5 

10.2.2  CALCOMP  Plotting  Symbols 

The  symbols  plotted  by  the  ARC  CDC  7600  installation  of  REVS  agree 
with  those  shown  in  Figure  5-2. 


10.2.3  Operating  Modes 

The  ARC  CDC  7600  installation  of  REVS  allows  the  use  of  the  on-line 
operating  mode  with  the  restriction  that  the  user  may  use  the  on-line  mode 
only  once  in  any  REVSXQT  step. 

10.2.4  TRW  PASCAL  Compiler 

Simulators  and  post  processors  generated  by  the  ARC  CDC  7600  installa- 
tion of  REVS  are  compiled  using  a TRW  PASCAL  compiler  which  Implements  the 
PASCAL  language  as  defined  in  [2].  Limitations  of  this  compiler  require  that 
elements  of  the  following  element  types,  when  used  in  simulating  requirements, 
must  be  unique  In  the  number  of  characters  specified: 

unique  in  7 characters  unique  in  10  characters 

FILE  DATA  (TYPE  not  ENUMERATION) 

ENTITY  TYPE  ENTITY  CLASS 

DATA  (with  type  ENUMERATION)  MESSAGE 


INPUT  INTERFACE 

outpuTjnterface 

ua  1 hoc  <r.  a RANGF  attribute 


- 


-• 

I fl 

Also,  the  Boolean  operators  EQU  and  XOR  defined  in  the  syntax  for  RSL 
are  not  recognized  by  this  PASCAL  compiler  and  should  not  be  used  in  the  ARC 
CDC  7600  installation. 

10.2.5  SCOPE  Loader 

The  standard  CDC  SCOPE  loader  [6]  is  used  to  link-edit  the  simulators 
and  post  processors  generated  by  the  ARC  CDC  7600  installation  of  REVS.  To 
insure  proper  link-editing,  elements  of  the  following  element  types,  when 
used  in  simulating  requirements,  must  be  unique  in  the  first  seven  characters: 
ALPHA,  PERFORMANCE_REQUIREMENT,  R_NET , SUBNET,  SUBSYSTEM,  VAL IDAT I 0N_P0 I NT . 
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EXTENDED  BNF  NOTATION 


Throughout  this  document,  the  syntax  of  the  Requirements  Statement 
Language  (RSL)  and  the  REVS  Control  Language  (RCL)  has  been  defined  in  a 
notation  which  is  called  extended  BNF  (Backus-Naur  Form).  This  notation 
Is  a loosely  formal  grammatical  representation  of  the  syntax. 

A grammar  is  composed  (at  least  in  part)  of  rules,  or  productions. 

Each  production  specifies  a textual  replacement;  by  starting  with  the 
chosen  initial  symbol,  and  substituting  as  necessary  using  the  produc- 
tions, all  1 eg itimate^  forms  (commands)  of  the  language  may  be  developed. 

Three  general  classes  of  symbols  appear  in  productions,  namely 
terminal  symbols,  non-terminal  symbols,  and  meta-linguistic  symbols. 

• Terminal  symbols  are  those  characters  and  character  strings 
which  will  actually  appear  in  a language  statement.  Examples 
of  terminal  symbols  for  RSL  include  words  such  as  "STRUCTURE", 
"TERMINATE",  any  of  the  element  names,  and  characters  such  as 
"."  and  "(".  Any  symbol  which  is  not  a non-terminal  or  meta- 
linguistic symbol  is  by  default  a terminal  symbol.  The 
terminal  symbols  may  be  grouped  into  two  classes. 

Individual  symbols,  such  as  punctuation  marks  (e.g., 

"(")  and  keywords  (e.g.,  "TERMINATE"),  are  those  symbols 
which  represent  themselves.  That  is,  they  appear  In  the 
BNF  exactly  as  they  will  appear  in  RSL  or  RCL.  Individual 
symbols  which  are  words  will  be  written  in  all  capitals. 

Class  Symbols,  such  as  "name"  and  "comment",  are  those 
symbols  which  denote  a whole  group  of  terminals  with  a 
formation  rule  to  define  the  constitution  of  the  class. 

Any  member  of  the  class  may  appear  in  the  language  state- 
ment or  command.  Class  symbols  will  be  written  in  lower 
case  letters.  Optional  prefixes  giving  semantic  infor- 
mation may  be  used  with  class  symbols.  An  example  of  this 
is  "element-name"  which  means  that  any  "name"  designating 
an  "element"  may  be  used. 

• Non-terminal  symbols  name  other  productions  In  the  language 
and  will  always  be  written  enclosed  in  corner  brackets.  For 
example  <set  definition>  is  a non-terminal  symbol  in  the  RADX 
RCL  syntax.  Examples  of  non-terminals  from  RSL  include  <new 
element  definition>  and  <relation  declaration>. 
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• Meta-linguistic  symbols  are  those  characters  used  to  write 
productions.  The  character  ll<"  and  ">"  are  such  characters, 
and  are  used  to  denote  non-terminal  symbols.  The  meta- 
linguistic symbols  in  addition  to  corner  brackets  ("<"  and 
">")  used  in  this  document  are  interpreted  as  follows: 

Braces  ("{"  and  "}")  are  used  to  indicate  possible 
repetition  of  the  phrase  written  within  the  braces.  The 
subscript  following  the  closing  brace  gives  the  minimum 
number  of  repetitions  allowed;  likewise,  the  superscript 
gives  the  maximum.  Thus 

( ) n 

<<node>) 

l n 

means  that  1 or  more  (with  the  upper  bound  indefinite) 
occurrences  of  <node>  may  be  used  at  that  point. 

Brackets  ("["  and  "]")  are  a shorthand  for  j ...  j^,  indi- 
cating that  the  enclosed  phrase  may  be  used  once  or 
omitted.  For  example, 

[MODIFY]  element-type-name  element-name. 

means  that  the  terminal  MODIFY  may  be  omitted. 

More  than  one  phrase  within  brackets  or  braces  (on  dif- 
ferent lines),  denote  that  exactly  one  of  the  phrases  is 
to  be  chosen  on  each  repetition.  The  choice  is  completely 
independent  from  one  repetition  to  the  next;  thus, 

generates  the  following  phrases: 

abd 

acd 

abbd 

abed 

acbd 

accd 


The  symbol  is  used  to  denote  the  definition  of  a 

non-terminal.  All  productions  are  of  the  form 

<non-terminal>: :=  phrase 

where  <non-terminal>  is  thereby  defined  to  be  "phrase". 

The  symbol  "|"  is  used  to  designate  alternatives.  If 
<a  or  b>  is  to  be  defined  to  be  A or  B,  the  production 
to  express  this  would  be 


<a  or  b> 
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GENERAL  SYNTAX  RULES 

The  RSL  and  RCL  grammars  have,  as  their  terminal  symbols,  words, 
punctuation  marks,  numbers,  text  strings,  and  comments.  Each  of  these 
terminals  is  discussed  in  the  following  paragraphs. 

Words 

The  word  is  a class  symbol  which  corresponds  to  the  intuitive  defini- 
tion of  a word  in  English.  It  is  a string  of  characters  starting  with  a 
letter  or  underscore  (except  with  RNETGEN  which  allows  only  a letter  as  the 
first  character),  and  continuing  with  letters,  digits  or  underscores  ( _ ). 
This  definition  is  shown  below  in  the  form  of  a syntax  diagram. 


The  word  is  terminated  by  one  or  more  blanks  or  punctuation  marks  (see 
below).  Note  that  the  end  of  a card  or  line  is  defined  to  be  an  extra 
character  which  is  read  as  a blank;  therefore,  no  word  may  be  split  over 
a card  boundary.  No  maximum  length  for  a word  is  specified  in  the 
language  definition  (BNF  or  syntax  diagram  forms),  however  words  are  re- 
stricted to  a maximum  length  of  60  characters. 

Words  are  divided  into  three  subclasses:  reserved  words,  optional 

words,  and  names. 

Reserved  Words  - Words  which  appear  as  keywords  in  the  BNF  and 
syntax  diagram  definitions  of  RSL  and  RCL  are  reserved  for  the  use  desig- 
nated in  the  definitions.  The  REVS  user  may  not  redefine  these  words 
for  his  own  use.  In  addition,  the  user  should  not  use  PASCAL  keywords 
except  in  BETAs,  GAMMAs,  and  TESTs. 


• ■ 
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Listed  below  are  the  RSL,  RCL  and  PASCAL  reserved  words. 


Executive  RCL  Keywords 


(Since  the  Executive  scans  REVS  input  for  Executive  Control  Statements 
caution  should  be  used  in  forming  Function  Control  Statements  so  as  not 
to  use  these  keywords  to  inadvertently  form  Executive  RCL  at  the  beginning 
of  a line  image. ) 


ADDFILE 

LOG 

RSLXTND 

ALL 

NEWPAGE 

SIMDA 

BOTH 

OFFLINE 

SIMGEN 

EXECRCL 

ONLINE 

SIMXQT 

FEND 

ONLY 

STEP 

FUNCTION 

OUTPUT 

STOP 

GO 

RADX 

TESTER 

IMPLIED 

RNETGEN 

TRANSPARENT 

JOB 

RSL 

RSl  and  RSL  Extension  Keywords 


ADD 

ERROR 

RECORD 

ALL 

EXCEPT 

RELATIONSHIP 

AND 

EXTENSION  PERMISSION 

RELATION 

APPLICABILITY 

FALSE 

REMOVE 

APPLICABLE 

FOR 

RENAME 

AS 

IDENTIFICATION 

RESCIND 

ATTRIBUTE 

IF 

RETURN 

COMPLEMENTARY 

INSERT 

RETYPE 

CONSIDER 

LEVEL 

SELECT 

CONTROL  PERMISSION 

MODIFY 

STRUCTURE 

DEFINE 

MOD 

SUBJECT 

DELETE 

NET 

SUCH 

DIV 

NOT 

TERMINATE 

DO 

OBJECT 

THAT 

EACH 

OR 

TRUE 

ELEMENT  TYPE 

OTHERWISE 

VALUE 

END 

PATH 

XOR 

EQU 

PERMISSION 
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MICROCOPY  RESOLUTION  TEST  CHAR! 


NATIONAL  BUREAU  Of  STANDARDS  1'IM* 


RADX  RCL  Keywords 


ALL 

HIERARCHY 

REFERS 

ANALYZE 

IMPLIED 

RELATION 

AND 

IN 

RELATIONSHIP 

ANY 

IS 

RSL 

APPEND 

LIST 

SEQUENCE 

ATTRIBUTE 

MAP 

SET 

BETA 

MINUS 

STRUCTURE 

BY 

MULTUPLE 

SUCH 

COMPLEMENTARY 

NO 

SUMMARY 

DATA  FLOW 

NONE 

THAT 

ELEMENT  TYPE 

NOT 

USING 

FROM 

OR 

WHERE 

GAMMA 

PLOT 

WHICH 

GROUP 

PRIMARY 

WIDTH 

HEIGHT 

PUNCH 

WITH 

HIER 

SIMGEN  Keywords 

RCL 

REFERRED 

WITHOUT 

ALL 

IDENT 

R NETS 

BETA 

IDENTIFICATION 

SIMULATION 

EXCLUDE 

INCLUDE 

SIMULATOR 

GAMMA 

IS 

TYPE 

ID 

R NET 

BETA/GAMMA  FILE  Access 

CREATE 

FIRST 

RECORD 

DESTROY 

FOR 

SELECT 

DO 

FROM 

SUCH 

EACH 

ENDFOREACH 

NEXT 

THAT 

TEST  Recording  Access 

DO 

FOR 

RECORDING 

EACH 

FROM 

RETRIEVE 

ENDFOREACH 

NEXT 

SUCH 

FIRST 

RECORD 

THAT 
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PASCAL 


AND 

FUNCTION 

PROGRAM 

ARRAY 

GO  TO 

RECORD 

BEGIN 

IF 

REPEAT 

CASE 

IN 

SET 

CONST 

LABEL 

THEN 

DIV 

MOD 

TO 

DO 

NIL 

TYPE 

DOWN  TO 

NOT 

UNTIL 

ELSE 

OF 

VAR 

END 

OR 

WHILE 

FILE 

PACKED 

WITH 

FOR 

PROCEDURE 

PDL  2 Extensions 

to  PASCAL 

ACCESS 

COMMON 

MACRO 

ALIGNED 

ESCAPE 

XOR 

BY 

EQU 

SIMXQT  RCL  Keywords 

END 

IS 

SIMULATOR 

ID 

RUN 

START 

IDENT 

SIMULATION 

TIME 

IDENTIFICATION 

SIMDA  RCL  Keywords 

ALL 

PERFORMANCE  REQUIREMENT 

TEST 

EXCEPT 

PERFORMANCE-REQUIREMENTS 

Optional  Words  - Optional  words  are  defined  in  RSL  as  part  of  a 
relation  definition  (see  Section  8.0,  Extending  the  Language  (RSLXTND 
Function)).  Once  defined,  an  optional  word  may  be  used  anywhere  in  the 
RSL  input  stream  and  is  essentially  ignored  by  the  RSL  translation  func- 
tion. (Note:  Optional  words  appearing  in  conditionals,  comments,  and 
text  strings  will  be  stored  in  the  ASSM.  Optional  words  should  not  be 
used  in  conditions  or  text  strings  containing  PASCAL  code;  they  will 
result  in  simulator  post/processor  compilation  errors.)  Optional  words 
can  appear  only  in  input  to  the  translator;  they  cannot  appear  in  RCL. 

If  a relation  definition  is  deleted  from  the  language,  the  optional 
word  is  deleted.  However,  an  optional  word  may  be  associated  with  more 
than  one  relation  and,  thus,  as  long  as  one  relation  associating  the 
optional  word  remains  defined,  the  optional  word  may  be  used.  Examples 
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of  possible  optional  words  are:  BY,  FROM,  IN,  OF,  TO,  WITH.  All  optional 


words  currently  defined  appear  in  the  RSL  concept  definitions  appearing  in 
Appendix  D,  Section  3. 

Names  - All  other  words  appearing  in  the  definition  of  RSL  and  RCL 
are  interpreted  as  names  which  take  on  user  specifiable  semantic  interpre- 
tation. Throughout  the  BNF  and  syntax  diagrams  appearing  in  the  appendices, 
prefixes  are  added  to  a terminal  symbol  name  to  indicate  the  semantic 
interpretation  which  is  Implied  by  using  a name  in  the  indicated  position. 

Punctuation  Marks 

Punctuation  marks  are  individual  symbols  which  correspond  roughly  to 
English  punctuations.  There  are  two  classes  of  punctuation  marks  recognized 
by  REVS. 

The  following  punctuation  marks  appear  explicitly  in  the  RSL  and  RCL 
syntax  and  are  therefore  reserved  for  those  uses  alone: 

. ( )<><=>==<>+_*/ 

The  other  class  of  punctuation  marks  is  Ignored  by  REVS  and  may  be 
used  to  improve  readability: 


These  punctuation  marks  cannot  be  used  in  a conditional. 

Numbers 

Number  is  a class  symbol  in  RSL  and  RCL  which  has  the  formation  rules 
for  numbers  that  are  found  in  PASCAL.  Specifically,  the  following  rules 
apply: 

<signed  number>::=  <sign>  <unsigned  number> 

<sign>: :=  + | - 

cunsigned  number>::=  <unsigned  integer>  | <unsigned  real> 


cunsigned  integer>::=  <digit  sequence> 


<digit  sequence> 


::=  jdigitj" 


<unsigned  real>::=  cunsigned  integer>  . <digit  sequence> 

| <unsigned  integer>  . <digit  sequence>  E <scale  factor> 

| <unsigned  integer>  E <scale  factor> 
cscale  factor>::=  cunsigned  integer>  | csign>  cunsigned  integer> 
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These  syntax  rules  are  summarized  in  the  following  diagrams. 

I 


Note  that  if  the  number  contains  a decimal  point,  at  least  one  digit  must 
precede  and  succeed  the  point.  Also,  no  comma  may  occur  in  a number. 

Text  Strings 

The  text  string  is  a class  symbol.  It  consists  of  any  sequence  of 
characters  surrounded  by  double  quotes  ( i . e . , " ...  "). 

Comment 

Comment  is  a class  symbol  which  consists  of  any  sequence  of  charac- 
ters beginning  with  (*  and  ending  with  *)  (i.e.,  (*  ...*)).  Coiments  in 
RSL  may  be  placed  only  where  specified  in  the  syntax.  Comments  may  be 
entered  through  RNETGEN  only  where  legal  in  the  corresponding  RSL  syntax. 
Comments  may  appear  anywhere  in  a RADX  command;  and  comments  are  not  legal 
in  any  other  portion  of  RCL. 
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REVS  EXECUTIVE  SUMMARY 

C.l  EXECUTIVE  RCL  SYNTAX 

Table  C.l  contains  a description  of  the  syntax  of  Executive  RCL  in 
the  Backus-Naur  Form  described  in  Appendix  A.  An  underline  is  used  in 
this  syntax  description  to  identify  the  assumed  keyword  when  an  optional 
keyword  is  omitted.  For  each  syntax  production  or  set  of  productions  for 
the  Executive  RCL  commands,  this  table  also  identifies  the  number  of  the 
section  in  this  document  where  the  command  is  described. 

Figure  C-l  shows  the  syntax  of  Executive  RCL  in  diagrammatic  form. 


. 


Table  C.l  Executive  RCL  Index 


EXECUTIVE  RCL  SYNTAX 


<REVS  Executive  command*: := 

<funct1on  select1on>  | <funct1on  end>  | <transparency  declaration* 

| <1nput  directive*  | <onl  Ine/offl  Ine  directive*  | <logg1ng  directive* 
| coutput  directive*  | <pag1ng  directive*  | estop  cotmand* 


<function  selection*:" 

[FUNCTION]  <function  name*,  [remark] 

<function  name>::= 

RSL  | RNETGEN  | RADX  | SIMGEN  | SIMXQT  | SIMDA  | RSLXTND  | TESTER* 


<function  end*: := 

FEND,  [remark] 


transparency  declaration*:" 

TRANSPARENT  string-of-l-to-8  characters,  [remark] 


<1nput  directive*: := 

ADDFILE  [TRANSPARENT]  access-name,  [remark] 


<online/offline  directive*:" 


GO 


ONLINE 

OFFLINE 

OPPOSITE 


[ONLY],  [display-remark] 


clogging  directive*: := 


L0G  [eXECRCL  * t remark] 


<output  directive*::' 

'ONLINE 
OFFLINE 
BOTH 
IMPLIED 


OUTPUT 


[remark] 


cpaging  directive*:" 

'offline' 

NEWPAGE  | °JjEJNE 
IMPLIED 


[off 1 1 ne-page-ti tl  i ng-remark] 


<stop  command*:: 
STOP 


’job  ’ 

STEP  - 
= £ 


[display-remark] 


*The  TESTER  function  is  reserved  for  software  developmer,  ? only. 


SECTION 

NUMBER 


4.0 


4.1 


4.1 


4.2.1 


4.2.2 


4.3 


4.4.1 


4.4.2 


4.4.3 


4.5 
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function  1i  reserved  for  toftware  development  use  only. 

Figure  C-1  Executive  RCL  Syntax  Diagrams 


directive  stop  comrund 


Executi 


/ 


C.2  EXECUTIVE  MESSAGES 

The  messages  output  by  the  REVS  Executive  are  identified  and  described 
below.  These  messages  appear  both  on  REVS.LOG  and  REVS. OUT  except  as  noted. 

XX  000  REVS  BASELINE  VERSION  = X,  (DATE  = TIME  = 

Identifies  the  version  of  REVS  being  executed,  showing  the  base- 
line number,  and  the  data  and  time  the  baseline  was  created.  It 
appears  at  the  beginning  of  the  print  file.  Executive  output 
follows  this  line. 

XX  001  FUNCTION  function-name  INITIATED. 

Identifies  the  REVS  function  being  initiated,  and  indicates  a 
change  of  state  from  executive  to  function.  On  REVS. OUT,  this 
line  is  padded  with  asterisks  to  highlight  the  state  change. 
Function  output  follows  this  line. 

XX  002  FUNCTION  function-name  COMPLETED. 

Identifies  the  REVS  function  which  is  terminating  and  indicates 
a change  of  state  from  function  to  executive.  On  REVS. OUT,  this 
line  is  padded  with  asterisks  to  highlight  the  state  change. 
Executive  output  follows  this  line. 

XX  003  DATA  BASE  OPEN  FAILURE. 

Indicates  that  the  ASSM  cannot  be  opened  for  use  and  therefore 
causes  an  immediate  REVS  termination. 

XX  004*  FEND  VIOLATION,  PROGRAM  ERROR:  ABORT. 

Indicates  a function  attempt  to  read  past  the  FEND  statement. 

This  should  only  occur  as  a result  of  a system/hardware  error. 

XX  005*  STOP  VIOLATION,  PROGRAM  ERROR:  ABORT. 

Indicates  an  executive  attempt  to  read  past  the  STOP  statement. 
This  should  only  occur  as  a result  of  a system/hardware  error. 

XX  006  NON  REVS-EXEC-RCL  STATEMENT:  IGNORED. 

Indicates  that  non-executive  RCL  statements  (l.e..  Function 
Control  Statements)  have  been  encountered  while  in  the  executive 
state.  This  message  appears  only  once  per  executive  state  regard- 
less of  the  amount  of  irrelevant  input.  This  may  be  a result  of 
the  misplacement  or  omission  of  Executive  RCL  statements  or  can 
occur  if  a function  prematurely  terminates  before  reading  all  its 
input. 

XX  007  REVS  COMPLETED:  NORMAL  TERMINATION. 

Indicates  normal  termination  of  REVS.  All  output  is  complete. 


I 


*This  message  appears  only  on  REVS.LOG. 

lb.,  i 
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XX  008  REVS  COMPLETED:  ABNORMAL  TERMINATION. 

Indicates  abnormal  termination  of  REVS.  Other  messages  indi- 
cating the  source  of  the  error  may  be  found  in  the  ASC  Job  Activity 
File  (SYS.JATF)  at  the  front  of  the  run,  or  in  the  REVS. OUT  listing. 
All  output  should  be  completed. 


XX  009  PDS  2 RUN-TIME  ERROR:  ABORT  IN  PROCESS 


j HARDWARE/STACK  OVERFLOW 
.UTILITY/LIBRARY 
'BOUNDS  CHECK 


Indicates  premature  termination.  The  suffix  of  the  message  gives 
a general  classification  of  the  error  detected: 

• HARD WARE/ STACK  OVERFLOW  means  a hardware  interrupt  or  PDS 
stack  overflow  has  occurred.  The  hardware  interrupt  means 
hardware  error,  program  error,  or  time  out  and  is  clarified 
on  REVS. OUT.  Time  can  be  increased  on  the  REVSXQT  macro. 

t UTILITY  LIBRARY  means  an  error  was  detected  by  the  PDS 
utility  library,  and  is  clarified  on  REVS. OUT. 

• BOUNDS  CHECK  means  a program  error  was  detected,  is  clari- 
fied on  REVS. OUT  and  probably  indicates  a hardware  error. 

XX  010*  XX HALT  TERMINATION  REQUESTED. 

Indicates  a programmed  emergency  termination  and  can  only  occur 
by  hardware  error. 

XX  Oil*  ADPFILE  COMPLETED:  RECORDS  READ  = number. 

Indicates  completion  of  the  reading  of  an  alternate  input  file. 

The  number  of  records  read  is  printed. 

XX  012  REVS  CHANGING  MODE  TO  ONLINE. 

Indicates  that  the  Executive  is  changing  the  operating  mode  to 
on-line.  Subsequent  output  is  to  the  on-line  console  unless 
specifically  routed  off-line  with  an  OUTPUT  statement. 

XX  013  REVS  CHANGING  MODE  TO  OFFLINE. 

Indicates  that  the  Executive  is  changing  the  operating  mode  to 
off-line.  Output  routing  is  governed  by  the  last  OUTPUT  statement. 

XX  014  PREVIOUS  GO  ONLY  ACTIVATED  STOP  ON  THIS  GO  STATEMENT. 

Indicates  a GO  statement  was  encountered  following  one  with  the 
ONLY  option  and  that  it  is  being  interpreted  as  a STOP  statement. 

XX  015  REVSGRAPH  RELEASE  OMISSION,  PROGRAM  ERROR:  EXEC  CORRECTED. 

Indicates  synchronization  error  between  the  Executive  and  a REVS 
function  over  control  of  the  on-line  console.  This  condition  can 
only  occur  as  the  result  of  a hardware  error. 

*This  message  appears  only  on  REVS.LOG. 
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XX  016  REVS  TERMINATING:  GO  OFFLINE,  STOP  IMPLIED. 


Indicates  REVS  is  terminating  while  still  in  the  on-line  mode. 
Previous  messages  on  REVS. OUT  explain  why.  This  message  appears 
on  the  on-line  console  only. 

XX  017*  ONLINE  USER  HAS  REQUESTED  INTERRUPT. 

Indicates  the  on-line  user  has  requested  a function  interrupt 
with  the  trackball  at  a page  wrap  opportunity.  Reaction  to  the 
request  is  function  dependent. 

XX  018  DEFAULT  ONLINE  IDENTIFICATION  USED:  user-name. 

Indicates  that  the  user  has  failed  to  provide  a personal  identifi- 
cation notice  in  the  comment  field  of  the  GO  ONLINE  statement  to 
be  shown  on  the  introductory  REVS  display  on  the  ANAGRAPH  on-line 
console.  A default  identification  is  thus  displayed  which  is  the 
user  name  from  the  job  card. 

XX  019*  ONLINE  CONSOLE  ACQUIRED  SUCCESSFULLY. 

Indicates  the  actual  time  that  REVS  achieved  the  on-line  mode. 
Comparison  with  the  time  of  the  previous  message  (XX  012)  reveals 
that  the  delay  is  due  to  non-availability  of  any  graphics  com- 
munication or  to  console  contention. 

XX  020*  user-identification  NOW  ACTIVE  ONLINF. 

Identifies  the  user  and  time  of  initial  on-line  response.  Com- 
parison with  the  time  of  the  previous  message  (XX  019)  reveals 
the  extent  of  a REVS  idle  condition  waiting  for  user  activity. 

XX  021*  NUMBER  OF  CARDS  PUNCHED  BY  REVS  IS  number. 

Indicates  the  number  of  cards  punched  by  REVS  as  a result  of 
RADX  punch  statements.  This  message  occurs  only  if  punched 
output  is  produced  (number  of  cards  > 0). 

XX  022*  NUMBER  OF  STRUCTURES  PLOTTED  = number,  MAXX  = number,  MAXY  - number. 

Indicates  the  number  of  structures  plotted  by  RNETGEN  and/or  RADX 
and  the  maximum  X and  Y plot  size  in  inches.  This  is  formatted  to 
ease  the  task  of  manually  completing  plot  requests  at  the  ARC. 
Plotting  is  automatically  completed  at  NRL. 


*This  message  appears  only  on  REVS.LOG. 
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APPENDIX  D 
RSL  SUMMARY 

D.l  RSL  SYNTAX 

Table  D.l  contains  a description  of  the  syntax  of  RSL  in  the  BNF 
notation  described  in  Appendix  A.  This  table  contains  the  syntax  for  only 
that  part  of  RSL  used  for  developing  requirements;  the  syntax  for  extending 
the  language  is  documented  in  Appendix  J.  For  each  syntax  production  or 
set  of  productions  for  the  RSL  commands,  this  table  also  identifies  the 
number  of  the  section  in  this  document  where  the  command  is  described. 

Figure  D-l  shows  the  syntax  of  RSL  in  diagrammatic  form.  Since  the 
formal  syntax  for  RSL  allows  statements  which  will  result  in  semantic  errors 
some  of  the  semantic  rules  have  been  incorporated  in  the  statement  of  the 
grammar  in  order  to  aid  the  user  of  RSL. 
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Table  D.l  RSL  Index 


i. 
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SECTION 

NUMBER 


conditional  branch*:  : = 

[unsigned  Integer]  <cond1t1on>  <branch» 


<cons1der-or  node> : : = 

consider -da  ta> 

I <consider-entity-class> 


<consider-data>::= 

CONSIDER  [DATA]  enumerated-data-name 
IF  [corment]  <cons1der-data  branch> 
|oR  <con$1der-data  branch*^ 

END 


<consider-data  branch>::  = 

|enumeration-value-name  /or  enumeration-value-name  | ) [<branch>] 


<consider-entity-class>: := 

CONSIDER  [ENTITYCLASS]  entity-class-name 
IF  [comment]  <cons1der-ent1ty  branch* 

joR  <consider-entity  branch*^ 

END 


<consider-entity  branch>::= 

(entity-type-name  joR  entity-type-name j J [<branch>] 


<for-each  node*::= 


4 [FILE]  file-name  [RECORD]  i* 

FOR  EACH  < [ENTITVJTYPE]  entity-type-name  > [SUCH  THAT  condition*] 
{ [ENTITY_CLASS]  entity-class-name  ) ^ 

DO  leo— ttj  {gffil’L'KlLi'K-eJt]}' 


< select  node* 


Dde>::=  , 

SELECT  { [E^lu^EfenJi^tyie-naT6  }.  SUCH  THAT  <condition>  [comment] 


<condition>  = 

(<Boolean  expression*) 

<Boolean  expression*:  : = 

<simple  Boolean*  (<B  op>  <simple  Boolean*l 
( ' 0 

<simple  Boolean*::® 

<Boolean  term  >|oR  <Boolean  term>|^ 

< Boolean  term* : 

<Boolean  factor*  |anD  <Boolean  factor*^ 

<Boolean  factor>::  = 

< Boolean*  [<rel  op*  < Boolean*] 

| arithmetic  expression*  <rel  op*  ^arithmetic  expression* 

< Boolean* 

[NOT]  < Boolean  primary* 

< Boolean  primary*  ::  = 

TRUE 
| FALSE 

| Boolean-data -name 

[ (<Boolean  expression*) 
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arithmetic  expression*::55 

[<ad  op>]  <arithretic  term*  |<ad  op>  arithmetic  term>|^ 
«arithmet1c  tern*::* 

<ar1thnet1c  factor*  |<nul  op*  arithmetic  factor>|^ 
<ar1thmet1c  factor*::* 
unsigned  number 
| arlthnetlc-data-rame 
| ^arithmetic  expression*) 

* <B  op*::* 

EQU  | XOR 
<re1  op*::* 

-|<|>|<*|>*|<» 

<ad  op>:  :* 

♦ I - 

«mul  op*::* 

* I / ! 01V  I "CO 


<element  modification*::* 

[MODIFY]  elcment-type-name  eicncnt-nam.e  [comment]. 

![ IfiSERT]  <eiement  definition  sentence* \n 
attribute  declaration  removal*  I 

relationship  declaration  removal*  > 

<structure  declaration  removal*  1 

<path  declaration  removal*  g 


attribute  declaration  removal*  ::  = 
REMOVE  attribute- name. 


<rclationshi p declaration  removal*::* 

REMOVE  relation-name  [relation-optional -word] 
| [elenent-type-name]  element  name  | . 

<structure  declaration  removal* : :=■ 

REMOVE  STRl'CTtRE. 


<path  declaration  removal*::* 
R F "OV " FtTK. 


<elcfrent  del etior,*: : = 

pr;  rrr  -t vn*-na~e  element-name. 


«clcnent  rename*: := 

pr\.V"  ftlm-f'fif.pi-r  AS  nnyy-nl  ement -P1r"n  f f rr—inn  t 1 . 


<clement  retype*::* 

RETYPE  elr'-ent-nj-e  AS  el  cnent-tvpe-n.ire. 


SECTION 

UMBER 


5.1 .1  .4 
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5. 1.2. 3 


5. 1.2. 5 
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5.1.4 
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• 

*See  Section  10  for  installation  dependent  restrictions. 
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Figure  D-1  RSL  Syntax  Diagrams 


attribute  declaration 


RSL  Syntax  Diagrams  (Continued) 


entity  class  name 


RSL  Syntax  Diagrams  (Continued) 


element  type  LJelonent 
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D.2  RSL  CONCEPT  CROSc-REFERENCE 

Table  D.2  provides  a cross-reference  between  the  standard  RSL  element 
types,  relationships,  attributes,  and  structures.  The  element  types  are 
partitioned  into  segments  corresponding  to  the  segments  which  introduce  and 
discuss  them  in  Section  3 of  this  document.  For  relationships,  attributes, 
and  structures  the  defining  segment  is  indicated  by  an  X. 

For  each  element  type  additional  entries  in  Table  D.2  indicate  whether 
the  element  type  may  be  the  subject  (S)  or  object  (0)  of  each  relationship 
and  also  whether  the  element  type  is  an  applicable  element  type  for  each 
attribute  (*).  If  an  element  type  may  appear  as  an  element  node  on  an  RSL 
structure,  the  appropriate  table  entry  contains  the  entry  A. 


Table  D.2  RSL  Concept  Cross-Reference  Chart 
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SS3N31333K03 


33IOHO 
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as 

as 
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aBoaaBaaaaBDDaiaaaaoDaDBDaa 
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IBIBBBUBBBBBBBB 
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SiN3W33dWI 


SWdOJ 


S3iyn03 


S339VN3 


S1N3K3300 
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SAV13C 


S31V3H3 
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S133NII03 
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IBBBBBBBIQHBBBHBBBBBBBBIBI 


BBBIBBB 
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ATTRIBUTE  APPLIES  TO  ELEMENT 


D.3  DEFINITIONS  OF  RSL  ELEMENT  TYPES,  RELATIONSHIPS,  ATTRIBUTES,  AND 
PREDEFINED  ELEMENTS 


Ei.EMENTiTYPEt  ALPHA 

(*  A BASIC  PROCESSING  STEP  IN  THE  FUNCTIONAL 
REQUIREMENTS,  *), 

STRUCTURE  APPLICABILITY!  NET, 

El'EMENT^TYPEi  OATA 

(*  A SINGLE  PIECE  OF  INFORMATION  OR  SET  OF 
INFORMATION  That  IS  EITHER  REQUIRED  IN  THE 
IMPLEMENTED  SOFTWARE  or  IS  needed  for 
DESCRIPTIVE  PURPOSES,  *), 

ElEMENT^TYPEi  decision 

(*  A CHOICE  OR  INTERPRETATION  THAT  HaS  BEEN  MADE 
IN  order  To  establish  functional  and/or 
performance  requirements  based  on  one  or  more 
originating_requirements,  this  means  that  the 
lower  level  REQUIREMENTS  ARE  A RESULT  OF 
DERIVATION,  not  SIMPLY  ALLOCATION'.  *), 

El'EMENT-^TYPEi  ENTITy~CLASS 

(*  A GENERAL  CATEGORY  of  objects  outside  the  data 
PROCESSING  SUBSYSTEM,  THE  OBJECTS  MAY  BE  REAL 

or  perceived  and  are  those  In  the  environment 

ABOUT  WHICH  THE  DATA  PROCESSING  SUBSYSTEM  MUST 

maintain  information,  for  example#  an 

ENTITyJDLASS  might  BE  TARGFT  OR  INTERCEPTOR, 
WHEN  THE  EXISTENCE  OF  AN  OBJECT  In  *N 
ENTITy"CLASS  IS  DETERMINED.  FILES  AND  DATA  MAY 
8£  TEMPORARILY  CREATED  TO  MAINTAIN  INFORMATION 
ABOUT  IT,  *), 

Element-^typei  entityItype 

(a  A SUBSET  WITHIN  A GENERAL  CLASS  CENT  I T Y_CL ASS ) 
OF  OBJECTS  OUTSIDE  THE  DATA  PROCESSING 
SUBSYSTEM  ABOUT  WHICH  THE  D*TA  PRsCESSOR  MUST 

maintain  information,  for  example# 
entity_types  within  the  entIty_class  target 
MIGHT  be  detection,  POTENTIALLY#  non. 
threatening#  threatening,  ETC.  when  a 

PARTICULAR  OBJECT  IN  AN  ENT  I TY.CL ASS  IS 

determined  to  be  of  a specific  type#  the 

OBJECT  CAN  BE  SET  TO  ThE  TYpE  AND  DATA  AND 
FILES  PERTINENT  to  objects  of  that  type 
temporarily  created  to  maintain  information 

ABOUT  THE  OBJECT,  *), 
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ElEMENT^TYPEi  event 

c*  AN  IDENTIFIED  POINT  IN  THE  SEQUENCE  OF 

PROCESSING  SPECIFIED  BY  ONE  8*  MORE  R_NETS  (OR 
SUBNETS)  WHICH  CAUSES  THE  ENABLEMENT  OF  AN 

r'net1.  an  event  may  be  used  to  specify  a 
VALIDATIONIPATH.  *). 

STRUCTURE  APPLICABILITY!  NET. 

STRUCTURE  APPLICABILITY!  PATH. 

ElEMENTqTYPEi  FILE 

(*  AN  AGGREGATION  OF  INSTANCES  OF  DATA#  EACH 

instance  of  which  is  treated  in  the  same 

MANNER,  *), 

ELEMENTBjTYPEi  inpuOnterface 

(*  A PORT  BETWEEN  THE  DATA  PROCESSING  SUBSYSTEM 
AND  ANOTHER  SUBSYSTEM  (E.G.#  A RADAR)  THROUGH 
WHICH  DATA  IS  PASSED  TO  Th?  DATA  PROCESSING 
SUBSYSTEM,  AN  INPUOnTERF ACE  APPEARS  AS  THE 
FIRST  NODE  OF  ONE  AND  ONLY  ONE  R'nET 
STRUCTURE,  *). 

STRUCTURE  APPLICABILITY!  NET. 

ELEMENTgTYPE!  MESSAGE 

(*  AN  AGGREGATION  OF  DATA  AND  FILES  THAT  PASS 
THROUGH  AN  INTERFACE  AS  A LOGICAL  UNIT,  *}, 

elements ype  i originating.requirement 

c*  a higher  level  requirement  from  which  lower 

LEVEL  REQUIREMENTS  (THOSE  EXPRESSED  IN  THE  RSL ) 

are  traceable,  *). 

Elementhtypei  outputZinterface 

(*  A PORT  BETWEEN  THE  DATA  PROCESSING  SUBSYSTEM 
AND  ANOTHER  PART  OF  THE  SYSTEM  (E’.G,,  A RADAR), 

through  which  data  is  passed  to  the  other 

SUBSYSTEM,  AN  OUTPUT^ INTERFACE  MaY  APPEAR  ON 
AN  R_nET  OR  SUBNET  STRUCTURE  AS  ThE  LAST  NODE 
OF  A PATH,  *), 

STRUCTURE  APPLICABILITY  I NET. 

Elementbtypei  performance  requirement 

(*  AN  ANALYTIC  performance  REQUIREMENT  or 

N0N*StIMULUS»RE8P0NSE  TIMING  requirement  WHICH 
IS  TO  BE  met  BY  THE  DATA  PROCESSING 
SUBSYSTEM,  *), 
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ELEHENTriTYPEi 


R 

C* 


NET 


the  order  of  logical  processing  that  must  be 

PERFORMED  0 y the  DATA  PROCESSING  SUBSYSTEM  in 

response  to  external  or  internal  stimuli,  the 

PROCESSING  STEPS  ARE  ALPHAS  OR  SUBNETS  WHICH 
may  be  EXPANDED  to  LOWER  LEVELS  Of  detail,  in 
ADDITION  TO  PROCESSING  STEPS,  THE  R_NET 
STRUCTURE  MAY  CONTAIN  INTERFACES,  EVENTS, 
VALIDATIONJ’OINTS,  ands,  ors,  selects,  AND  FOP 
EACH  NODES;  IT  MUST  BE  ENABLED  ANd 

terminated,  *). 


ElEMENT^TYPE  t 


SOURCE 

(*  SOURCE  OR  AUXILIARY  MATERIAL  FOR  REQUIREMENTS, 
I.E.,  ORIGINATING  POINT  FOR  ONE  OR  MORE 
ORIGINATING^REOUIREMENTS,  DOCUMENTATION  of 
TRADE-OFF  STUDIES,  OR  BACKGROUND  material  for 
REQUIREMENTS  ELEMENTS,  *). 


ElEMENT’ITYPEi  SUBNET 

(*  a sequence  er  logical  processing  steps 

MUST  be  PERFORMED  TO  ACCOMPLISH  THE 
REQUIREMENTS  0*  THE  NEXT  HIGHER  NETWORK 
(SUBNET  OR  R NET),  *), 

STRUCTURE  aPPL IC AB I L I T y i NET, 


THAT 


ElEMENT.^TYPEi 


SUBSYSTEM 

(*  A PART  OF  THE  SYSTEM  (E.G..  A RADaR)  WHICH 
COMMUNICATES  WITH  THE  DATA  PROCESSING 
SUBSYSTEM,  *), 


Element  3TYPE1 


SYNONYM 

(*  A SYNONYM  IS  AN  ALTERNATE  NAME  THAT  CAN  BE  USED 
IN  PLACE  OF  THE  PRIME  NAME  OF  AN  FLUENT,  IT 
IS  USED  AS  AN  ABBREVIATION  IN  MOST  CASES,  BUT 
MAY  BF  USED  FOR  OTHER  REASONS,  NflTE | IN  THE 
RSL  DEFINITIONS  OF  RELATIONSHIPS  AND 
attributes,  !:*LL"  always  IMPLIES  mall  EXCEPT 

SYNONYM",  *). 


element  tType i 


UNSTRUCTURED 'REQUIREMENT 

(*  A REQUIREMENT  THAT  MUST  BE  PASSED  TO  THE 
SOFTWARE  DESIGNER  BUT  that  DOES  not  FIT  INTO 
THE  STRUCTURED  FRAMEWORK  PROVIDED  BY  RSL,  THIS 
element  MIGHT  BE  USED  BECAUSE  THE 
REQUIREMENT  in  QUESTION  IS  TOO  UNCOMMON  TO 
JUSTIFY  DEFINITION  OF  A NEW  TYPE  OF  ELEMENT,  A 

new  Relationship,  or  a new  attribute,  can 
example  of  an  unstructuredjjRequirement  might 

be  PRECLUSION  of  USING  A MULTIPROCESSOR  WITH 
ASSOCIATIVE  MEMORY,)  *). 
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El'EMENT3!TYPE| 


VALIDATION~PATH 

C*  A PATH  8 P PROCESSING  OVER  wHICH  QUANTITATIVE 
validation  testing  will  be  PERFORMED,  A path 
is  specified  USING  VALIDATION.POInTS  and 
EVENTS  AND  MUST  CORRESPOND  TO  A ROUTE  THR8UGH 
AN  R_NET  OR  THROUGH  RjNETS  CONNECTED  BY 

events.  *), 

El'ERENTpTYPEi  VALIDATI8N~P0INT 

l*  A LOGICAL  POINT  JN  THE  PROCESSING  SPECIFIED  BY 
AN  R_NET  OR  SUBNET  AT  WHICH  DATA  MUST  BE 
OBTAINABLE  IN  the  IMPLEMENTED  SOFTWARE  IN  ORDER 
TO  VALIOATE  THAT  THE  PERFORMANCE  REQUIREMENTS 
HAVE  BEEN  FULFILLED,  •), 

STRUCTURE  APPLICABILITY!  NET. 

STRUCTURE  APPLICABILITY!  PATH, 

ELEMENTfTYPEi  VERSION 

C*  THE  AGGREGATION  OF  REQUIREMENTS  THAT  ARE  TO 
APPLY  AS  A UNIT  TO  THE  DATA  PROCESSING 
SUBSYSTEM  AT  A PARTICULAR  TIME,  l'OOP.I, 

L80P_a,  ETC.,  ARE  VERSIONS.  AS  IS  AN  IOC 
SYSTEM,  *). 

RELATIONSHIP!  ASSOCIATES 

(*  IDENTIFIES  WHICH  DATA  AND  FILES  COME  INTO 
EXISTENCE  WHEN  A DATA  PROCESSING  STEP  (AN 
ALPHA)  EITHER  CREATES  AN  INSTANCE  OF  AN 
ENTITv.CLASS  OR  SETS  THE  EnTITY_TyPE  of  AN 
INSTANCE  OF  AN  ENT  I T Y^CL ASS . DATA  AND  FILES 
CAN  Be  ASSOCIATED  WITH  ONLY  ONE  ENT  I T Y_CL ASS . 

data  and  files  may  be  associated  with  several 

ENTITy_TYPES  PROVIDED  THE  eNTITYItYPES 
compose  the  same  entityIclaSS.  data  and  files 
that  are  ASSOCIATED  WITH  AN  ENTITyITyPE  or 
ENTITy_CLASS  may  NOT  ALSO  make  a MESSAGE,  data 
THAT  is  associated  WITH  an  entitybtype  or 
ENTITy_CLASS  may  not  ALSO  be  CONTAINED  in  A 

file.  *). 

COMPLEMENTARY  RELATIONSHIP!  ASSOCIATED  {"WITH")'. 

SUBJECT  ELEMENTfTYPEi  ENTITYjCLASS 

ENTITYjTYPE, 

OBJECT  ELEMENT_TYPE|  DATA 

FILE. 


RELATIONSHIP!  COMPOSES 

I*  IDENTIFIES  TO  WHICH  ENTlTYfiCLASS  aN  ENTITY^TYPE 

belongs,  an  entitybtype  composes  only  ONE 
ENTITy^CLASSJ  an  ENTITyIClaSS  IS  COMPOSED  of  at 
LEAST  ONE  ENTITY.TYPE,  *). 

COMPLEMENTARY  RELATIONSHIP!  COMPOSED  ("OF'’). 

SUBJECT  ELEMENT.TYPEi  ENTITYjTYPE, 

OBJECT  ELEMENT.TYPEl  ENTITYJCLASS, 
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RELATIONSHIP!  CONNECTS  ("TO") 

C*  IDENTIFIES  WITH  WHICH  SUBSYSTEM  ThE 
INPUT'UNTERFACE  OR  OUTPUTTiNTERFAcE 
COMMUNICATES,  an  interface  CONNECTS  to  only 

ONE  SUBSYSTEM,  *), 

COMPLEMENTARY  RELATIONSHIP!  CONNECTED  ("TO"), 

SUBJECT  ELEMENT_TYPE|  input.interface 

OUTPUTjINTERFACE, 

OBJECT  ELEMENT.TYPEl  SUBSYSTEM, 

RELATIONSHIP!  CONSTRAINS 

(*  IDENTIFIES  TO  WHICH  vALIDAtION>AtH(S)  THE 
PERFflRMANCE_REQUlREMENT  APPLIES,  *), 
COMPLEMENTARY  RELATIONSHIP!  CONSTRAINED  ("BY"), 

SUBJECT  ELEMENT.TYPEi  PERFORMANCEIREQUIReMENT, 

OBJECT  element.typei  validation^path, 

RELATIONSHIP!  CONTAINS 

(*  IDENTIFIES  THE  MEMBERS  OF  EACH  INSTANCE  IN  A 
file,  DATA  may  BE  CONTAINED  IN  Only  one  file, 
DATA  THAT  IS  CONTAINED  IN  A FILE  MAY  NOT  ALSO 
MAKE  A MESSAGE  NOR  MAY  IT  BE  ASSOCIATED  WITH  AN 
entity.class  OR  ENTITY^TYPE.  *). 

COMPLEMENTARY  RELATIONSHIP!  CONTAINED  ("lN«), 

SUBJECT  ELEMENTlTYPEt  file, 

OBJECT  ELEMENT. TYPE!  OATA, 

RELATIONSHIP!  CREATES 

(*  INDICATES  THAT  THE  ALPHA  CREATES  aN  INSTANCE  OF 
THE  ENTITY.CLASSCES) , CREATION  Of  an  ENTITY 
INSTANCE  IN  A CLASS  OCCURS  IMMEDIATELY  AT  THE 
BEGINNING  OF  AN  ALPHA  WHICH  CREATES  THE 
ENTITY.CLASS,  ONLY  ONE  NEW  ENTITY  INSTANCE  IS 
CREATED,  *), 

COMPLEMENTARY  RELATIONSHIP!  CREATED  <"8v«), 

SUBJECT  ELEMENT  TYPE!  ALPHA, 

OBJECT  ELEMENT.TYPEl  ENTlTYlCLASS, 

RELATIONSHIP!  DELAYS 

c*  the  enablement  of  r^nets  by  the  event  is 

POSTPONED  FOR  the  AMOUNT  OF  TIME  SPECIFIED  IN 
THE  Data,  only  one  data  may  DELAY  an  EVENT! 
THIS  DATA  MUST  NOT  INCLUDE  OTHER  DATA,  FOR 
SIMULATION  PURPOSES,  THE  VALUE  OF  THIS  DATA 
MUST  BE  IN  UNITS  OP  SECONDS.  *). 

COMPLIMENTARY  RELATIONSHIP!  DELAYED  ("BY"), 

SUBJECT  ELEMENTlTYPfi  DATA, 

OBJECT  ELEMENT.TYPEI  EVENT, 


r 


/ 


RELATIONSHIP!  DESTROYS 

(*  INDICATES  that  THE  ALPHA  DESTROYS  an  instance 
(THE  CURRENTLY  SELECTED  One)  OF  ThE 
ENTITy^CLASSCES) . IDENTIFICATION  OF  THE 
INSTANCE  IS  PERFORMED  BY  A SELECT  OR  FOR  EACH 

node  on  a network,  destruction  of  the  instance 
OCCURS  IMMEDIATELY  before  completion  of 
processing  in  the  ALPHA,  *), 

COMPLEMENTARY  RELATIONSHIP!  DESTROYED  ("8*"), 

SUBJECT  ELEMENT.TYPEi  ALPHA* 

OBJECT  ELEMENT_TYPEl  ENTITY_CLA33. 

RELATIONSHIP!  DOCUMENTS 

(*  THE  SOURCE  MATERIAL  PROVIDE®  AUXILIARY 

Information  about  or  is  the  originating  point 
for  The  OBJECT  ELEMENT, 

COMPLEMENTARY  RELATIONSHIP!  DOCUMENTED  ("BY"), 

SUBJECT  ELEMENT_TYPE|  SOURCE, 

OBJECT  ELEMENT.TYPEl  ALPHA 

DATA 

DECISION 

entity~class 

ENTITY_TYPE 

EVENT 

FILE 

input_interface 

MESSAGE 

originatingirequirement 

outpuOnterface 

PERFORM aNCE^REQuIREmENT 

R..NET 

SUBNET 

SUBSYSTEM 

unstructured "requirement 
validation"path 
VALIDATION.POINT 
VERSION, 

RELATIONSHIP!  ENABLES 

(*  INOICaTES  THAT  WHEN  THE  PROCESSING  CONTROL  FLAW 
PASSES  THROUGH  THE  EVENT  ON  AN  RjgET,  OR  WHEN 
DATA  IS  AVAILABLE  AT  THE  InPUONtERFACE,  THE 
FUNCTIONAL  PROCESSING  SPECIFIED  By  THE  R>ET 
CAN  BE  BEGUN,  AN  R"NET  MUST  BE  ENABLED  AND  CAN 
BE  ENABLED  EITHER  BY  ONE  AND  ONLY  ONE 
INPUT '^INTERFACE  OR  BY  ONE  OR  MORE  EVENTS,  *), 
COMPLEMENTARY  RELATIONSHIP!  ENABLED  ("BY"), 

SUBJECT  ELEMENT.TYPEi  EVENT 

inpuOnterface. 

OBJECT  ELEMENT.TYPEl  R.NET, 
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RELATI9nSHIP|  EQUATES  ("TO") 

(*  defines  an  alternate  name  for  an  element,  THE 

OBJECT  OF  EQUATES  IS  CALLED  THE  PRIME  NAME, 

THE  SUBJECT  NAME  CAN  BE  USED  FOR  INPUT  TO  THE 
ASSM,  BUT  ALL  RELATIONSHIPS,  ATTRIBUTE'S,  AND 
STRUCTURES  SO  DEFINED  ARE  ACTUALLY 
CHARACTERISTICS  OF  THE  PRImE  NAME'.  *), 
COMPLEMENTARY  RELATIONSHIP!  EQUATED  ("TO**), 

SUBJECT  ELEMENT_TYPE|  SYNONYM, 

OBJECT  ELEMENT.TYPEl  ALPHA 

DATA 

DECISION 
ENTITY'  CLASS 

entity”type 

EVENT 

FILE 

input_interface 

MESSAGE 

origin at ing^requirement 
output~intepface 

PERFORMANCE'REQUIREMENT 

r_net 

SOURCE 

SUBNET 

subsystem 

UNSTRUCTUREDIREQUIRfMENT 

validation~path 

validation_point 

version, 

RELATIONSHIP!  FORMS 

(*  INDICATES  that  the  ALPHA  ESTABLISHES  the 
message  as  the  one  to  be  passed  by  the 

CORRESPONDING  OUTPUTUnTERF AC.E  (ThE 
OUTPUT  INTERFACE  WHICH  PASSES  THE  MESSAGE) 

WHEN  THAT  INTERFACE  IS  ENCOUNTERED  On  THE  NET, 
AN  ALPHA  MAY  FORM  SEVERAL  MESSAGES  PROVIDED 

they  are  passed  by  different 

OUTPUT^INTERFACES,  *), 

COMPLEMENTARY  RELATIONSHIP!  FORMED  ("BY"). 

SUBJECT  ELEMENT"TYPEi  ALPHA, 

OBJECT  ELEMENT_TYPEl  MESSAGE, 
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Relationship!  implements 

c*  defines  the  versisn(s)  to  which  the  element 

APPLIES,  *), 

COMPLEMENTARY  RELATIBNSHIPI  IMPLEMENTED  ("BY"), 

SUBJECT  ELEMENT.TYPEi  ALPHA 

data 

OECISIBN 

entity^-class 

ENTITYjTYPE 

event 

FILE 

INPUT  INTERFACE 
MESSAGE 

briginatingIrequirement 

BUTPUT  INTERFACE 

PERFBRMANCE.REQUIReMENT 

R.NET 

SUBNET 

SUBSYSTEM 

UNSTRUCTURED-REQUIREMENT 
VALIDATION  PATH 
VAlIOATIO  N_P  8 1 N T , 

OBJECT  ELEMENT.TYPEl  VERSION,  . 

RELATIOnSHIRi  includes 

(*  indicates  a HIERARCHICAL  RELATIONSHIP  between 
DATA,  IF  A INCLUDES  B,  THEN  OBTAINING  A WILL 
OBTAIN  B,  »), 

COMPLEMENTARY  RELATIBNSHIPI  INCLUDED  ("IN"). 

SUBJECT  ELEMENT.TYPEi  cata. 

OBJECT  ELEMENT.TYPEl  DATA, 

RELATIOnSHIPi  INCORPBRaTES 

(*  INDICATES  A HIERARCHICAL  RELATIONSHIP  between 
ORIGINATING-P-EQUIREMENTS,  The  SCflPE  OF  THE 
SUBJECT  (HIGHER  LEVEL)  ORJgINATINg'REQUIREMENT 

includes  the  bbject  (lower  level) 

0RIGINATING_REQUIREMENT,  *), 

COMPLEMENTARY  RELATIBNSHIPI  INCORPBRaTED  ("IN")’. 

SUBJECT  ELEMENT.TYPEl  BRIGINATING^REQUIREMENT, 

OBJECT  ELEMENT.TYPEl  BRIGINATING.REQUIREmENT, 

RELATIONSHIP!  INPUTS 

(*  IDENTIFIES  THE  DATA  AND  FILES  USED  3Y  THE 
ALPHA,  *), 

COMPLEMENTARY  RELATIBNSHIPI  INPUT  ("TO"). 

SUBJECT  ELEMENT.TYPEi  alpha, 

OBJECT  ELEMENT.TYPEl  DATA 

FILE. 
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RELATIOnSHIPi  MAKES 

C*  INDICATES  THAT  THE  DATA  OR  FILE  is  a logical 
COMPONENT  OF  THE  MESSAGE,  a DATA  OR  FILE  MAY 
MAKE  SEVERAL  MESSAGES,  DAT A AND  FILES  THAT 
MAKE  A MESSAGE  MAY  NOT  ALSO  BF  ASSOCIATED  WITH 
an  entityItype  or  entitvIclass,  data  THAT 
MAKES  A MESSAGE  MAY  NOT  ALSO  BE  CONTAINED  IN  A 
FILE,  *). 

COMPLEMENTARY  RELATIONSHIP!  MADE  ("By”). 

SUBJECT  ELEMENT^TyPEi  DATA 

file, 

OBJECT  ELEMENT.TYPEI  MESSAGE. 

RELATIOnSHIPi  ORDERS 

i*  indicates  that  the  value  of  the  data  is  used  to 
ORDER  The  INSTANCES  OF  The  FILE,  a file  may  be 
ORDERED  BY  ONLY  ONE  DATA;  THE  DATA  MAY  NOT 
include  other  data  and  SHOULD  BE  CONTAINED  in 
THE  FILE,  *). 

COMPLEMENTARY  RELATIONSHIP!  ORDERED  ("BY"), 

SUBJECT  ELEMENT.TYPEi  DATA, 

OBJECT  ELEMENT.TYPEi  FILE, 

RELATIOnSHIPi  OUTPUTS 

(*  IDENTIFIES  THE  DATA  AND  FJlES  WHOSE  VALUES  OR 
CONTENTS  ARE  MODIFIED  BY  the  alpha.  *), 
COMPLEMENTARY  RELATIONSHIPI  OUTPUT  ("FROM"), 

SUBJECT  ELEMENT_TYPE|  ALPHA, 

OBJECT  ELEMENT_TYPE|  DATA 

FILE, 

' RELATIONSHIP!  PASSES 

(*  IDENTIFIES  THE  LOGICAL  UNITS  OF  INFORMATION 
WHICH  ARE  PASSED  THROUGH  ThE  INTERFACE,  AN 
INTERFACE  MAY  PASS  SEVERAL  MESSAGES!  A GIVEN 
MESSAGE  MAY  BE  PASSED  THROUGH  ONLY  ONE 
INTERFACE,  *), 

COMPLEMENTARY  RELATIONSHIP!  PASSED  ( " THROUGH" ) , 

SUBJECT  ELEMENT~TYPE|  input“interface 

output^interface, 

OBJECT  ELEMENT..TYPEI  MESSAGE, 

RELATIOnSHIPi  RECORDS 

(*  IDENTIFIES  THE  PARTICULAR  DATA  AND  FILES  WHICH 
ARE  TO  BE  MADE  AVAILABLE  AT  THE 

validation_point  for  performance 

EVALUATION,  *). 

COMPLEMENTARY  RELATIONSHIPI  RECORDED  ("By"). 

SUBJECT  ELEMENT_TYPE|  valioation.point, 

OBJECT  ELEMENT.TYPEI  data 

FILE. 
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RELATIONSHIP!  SETS 

(*  INDICATES  THAT  THE  alpha  establishes  AN 
INSTANCE  (THE  CURRENTLY  SELECTED  ONE)  OF  AN 
ENTITV_CLASS  TO  BE  OF  THE  £NTITY~TYPE, 
IDENTIFICATION  OF  THE  INSTANCE  IS  PERFORMED  BY 
A SELECT  OR  FOR  EACH  NODE  qN  A NETWORK,  AN 
ALPHA  MAY  SET  SEVERAL  ENT  I tT'T YPEs  PROVIDED  THE 
entity_tvpes  do  not  compose  the  same 
entity_class,  the  setting  of  AN  ENTITY.TYPE 
occurs  immediately  IN  AN  ALPHA  SUBSEQUENT  to 
ANY  ENTITY  CREATIONS,  *), 

COMPLEMENTARY  RELATIONSHIP!  SET  ("BY"), 

SUBJECT  ELEMENT„TYPE!  ALPHA1 
OBJECT  ELEMENT.TYPEl  ENT  I T YiTYPE , 

RELATIONSHIP!  TRACES  ("TO1*) 

(*  IDENTIFIES  THE  ELEMENTS  (LOWER  LEVEL 

REQUIREMENTS)  TO  OR  FROM  WHICH  THE  HIGHER 
LEVEL  REQUIREMENT  (ORIGINatInG^REquIREMENT  OR 
DECISION)  HAVE  BEEN  ALLOCATED  OR  DERIVED,  •), 
COMPLEMENTARY  RELATIONSHIP)  TRACED  <»FRom',)i 
SUBJECT  ELEMENVTYPEi  DECISION 

ORIGIN AT ING^REQUIReMENT, 

OBJECT  ELEMENT.TYPEl  ALPHA 

DATA 

DECISION 

entity^class 

ENTI TY_T YPE 

EVENT 

FILE 

inpuOnterface 

MESSAGE 

output'interface 

PERFORMaNCE_REQUIREm£NT 

R.NET 

subnet 

SUBSYSTEM 

UNSTRUCTUREDlREQUlREMENT 

validation^path 

VALIOATION_,9OINT 

VERSION, 


ATTRIBUTE!  ALTERNATIVES 

(*  THE  ALTERNATIVES  THAT  HAVE  BEEN  CONSIDERED  TO 
RESOLVE  A PROBLEM  RESULTING  In  A DECISION,  *), 
APPLICABLE  ELEMENOyPEI  DECISION, 

valuei  text. 
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ATTWISUTE « artificiality 

(*  THE  DEGREE  OF  FLEXIBILITY  ALLOWED  IN  IMPLEMENTING 
THE  ELEMENT  IN  THE  SOFTWARE,  *), 

APPLICABLE  ELEMENOyPEI  ALPHA 

DATA 

entity"class 

entity.type 

event 

file 

input_interface 

MESSAGE 

BUTPUTllNTERFACE 

R.NET 

SUBNET 

validationJpath 

validationIpbint. 

value  I ARTIFICIAL 

(*  the  element  has  been  defined  for  explanatory  or 
simulation  purposes  in  THE  REQUIREMENTS  statement 
and  NEED  not  BE  PRESENT  IN  the  SOFTWARE,  a), 

VALUE  I VALIDATION 

(A  THE  ELEMENT  IS  NECESSARY  FOR  PERFORMANCE 

REQUIREMENTS  evaluation  but  IS  not  REQUIRED  In  THE 
OPFRATIONAL  SOFTWARE,  *), 

VALUe I IMPLEMENT_PRECISELY 

(a  THE  ELEMENT  MUST  8E  IMPLEMENTED  IN  THE  SOFTWARE 
EXACTLY  as  defined,  a). 

VALUE  I IHPlEMENT.APPROXIMaTELY 

(*  the  element  must  be  implemented  in  the  software, 

8UT  the  precise  IMPLEMENTATION  is  left  to  the 
PROCESS  DESIGNER,  4). 

AtTRIBUtEi  beta 

(4  THE  PROCEDURAL  code  (PASCAL)  FOR  FUNCTIONALLY 
MODELING  THE  PROCESSING  STEP.  THE  CODE  IS  NOT 
PROCESSED  BY  THE  RSL  TRANSLATOR  BUT  IS  PROCESSED 
by  the  simulation  generation  function  and  the 
COMPILER.  a beta  may  use  the  special  create, 
destroy,  select  and  for  each  operations  on 

FILES,  a), 

APPLICABLE  ELEMENT_TyPE|  ALPHA, 

valufi  text, 

ATTRIBUTE!  CHOICE 

(*  THE  ALTERNATIVE  SELECTED  TO  SOLVE  A PROBLEM 
LEADING  TO  A DECISION,  THE  RaTIONALF  FOR  THE 

choice  should  be  included  here.  *). 

APPLICABLE  ELEMENOyPEi  DECISION, 

VALUE!  TEXT. 


D-25 


attribute i completeness 

(*  THE  DEGREE  TO  WHICH  THE  DEFINITION  Of  AN  ELEMENT  IS 
IN  FINAL  FORM,  *). 

APPLICABLE  ELEMENTjTYPEl  ALPHA 

DATA 

DECISION 

ENTITY'ICLASS 

entity_type 

EVENT 

FILE 

input.interface 

MESSAGE 

originating"reouI«ement 

output'interface 

PERFORMANCEIREQuIREMENT 

r_net 

SOURCE 

SUBNET 

SUBSYSTEM 

UNSTRUCTUREDlREQUIREMENT 

VALIDATION'PATH 

VALIDATION.POINT 

VERSION, 

VALUE!  CHANGEABLE 

(•  although  all  relationships,  ATTRIBUTES,  and 

STRUCTURES  MAY  BE  DEFINED  FOR  THE  ELEMENT , SOME  OF 
THEM  WILL  PROBABLY  BE  CHANGED,  INFORMATION  ABOUT 
THE  ELEMENT  IS  BELIEVED  TO  BE  CORRECT,  BUT  IS 
SUBJECT  TO  CHANGE,  *). 

VALUE!  INCOMPLETE 

<*  the  definition  of  THE  element  is  KNOWN  TO  BE 
INCOMPLETE’.  therefore,  even  if  RELATIONSHIPS, 
attributes,  and  structures  are  stated,  the  element 

DEFINITION  IS  STILL  INCOMPLETE.  *), 

VALUE!  COMPLETE 

(*  THE  DEFINITION  OF  THE  ELEMENT  SHOULD  BE  ASSUMED  TO 
BE  COMPLETE  AND  WILL  PROBABLY  NOT  CHANGE,  *), 
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attribute • description 

<*  ANY  FREE  FARM  TEXTUAL  MATERIAL  DESCRIBING  THE 
ELEMENT,  *), 

APPLICABLE  ELEMENOYPEi  ALPHA 

DATA 

DECISION 
ENT  I T Y~CLASS 
ENT  I TY_T YPE 
EVENT 
FILE 

INPUT.INTERFACE 

MESSAGE 

ORIGINATING^REQuIREMENT 

OUTPUTllNTERFACE 

PERFORMANCEIREQuIREMENT 

R_NET 

SOURCE 

subnet 

SUBSYSTEM 

unstructuredIrequirement 

VALIDATIONlPATH 

VALinATlON'POlNT 

VERSION, 

VALUFI  TEXT, 


attributEi  entered~by 

(*  THE  IDENTITY  of  THE  LAST  PERSON  TO  ENTER 
INFORMATION  ABOUT  THE  ELEMENT*.  *), 
APPLICABLE  ELEMEN71!TvPEI  ALPHA 

DATA 

OECISION 
ENTITY"CLASS 
ENTITY  TYPE 
EVENT 
FILE 

INwuT_INTERFACE 

MESSAGE 

criginating'requIREment 

output-interface 

PERFORMANCE "REQUIREMENT 

R..NET 

SOURCE 

SUBNET 

SUBSYSTEM 

UNSTRUCTUREDiREOUlREMENT 

VALIDATIOn'PATH 

VALIDATI0N„P0IMT 

VERSION, 

valuei  TEXT, 
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ATTRIBUTE!  gamma 

(*  THE  PROCEDURAL  CODE  (PASCAL)  FOR  ANALYTICALLY 
MODELING  A PROCESSING  STEP,  T«E  CODE  IS  NOT 
PROCESSED  BY  THE  RSL  TRANSLATOR  BUT  IS  PROCESSED  BY 
THE  SIMULATION  GENERATION  FUNCTION  A n D THE 

compiler,  a gamma  may  use  the  special  create, 
destroy,  select  and  for  each  operations  on 

FILES,  *), 

APPLICABLE  ELEMENOyPE!  ALPHA, 

VALUEI  text, 


ATTRIBUTE!  INITIALJVALUE 

(*  THE  INITIAL  VALUE  A DATA  ITEM  IS  REQUIRED  TO  HAVE 
IN  THE  IMPLEMENTED  SOFTWARE,  THIS  VALUE  WILL  BE 
ASSUMED  BY  THE  DATA  ITEM  WHEN  IT  COMpS  INTO 
EXISTENCE  IN  A SIMULATION,  *)'. 

APPLICABLE  ELEMENOyPE!  DATA, 

VALUE!  NAMED. 

VALUE!  NUMERIC, 


ATTRIBUTE!  LOCALITY 

(*  THE  ACCESSIBILITY  AND  LIPETIME  OF  A DATA  OR 
FILE,  *)'. 

APPLICABLE  ELEMENOyPE!  DATA 

FILE. 

VALUE!  GLORAL 


(*  GLOBAL  DATA  AND  FILES  ARE  ACCESSIBLE  0Y  MORE  THAN 
ONE  R_NET  AND  MAY  EXIST  THROUGHOUT  EXECUTION  OF  THE 
SYSTEM*  Data  and  FILES  which  are  ASSOCIATED  WITH  AN 
ENTITY.TYPE  or  an  entity~class  are  BY  DEFINITION 
GLOBAL.  *). 

VALUE!  LOCAL 


(*  LOCAL  data  AND  FILES  ARE  ASSOCIATED  WITH  the  r'nets 
IN  WHICH  They  ARE  USED  and  EXIST  only  DURING  the 
INVOCATION  OF  THE  RJNET  TO  WHICH  THEY  aRE  LOCAL, 
data  AND  FILES  WHICH  make  a message  are  by 
DEFINITION  LOCAL,  *)' 


ATTRIBUTE!  MaXIMUM^TIME 

(*  THE  MAXIMUM  TIME  THAT  CAN  BE  TAKEN  To  TRAVERSE  THE 
VALIDATlON_PATH,  THE  TIME  IS  SPECIFIED  IN  THE  UNITS 
STATED  IN  THE  UNITS  ATTRIBUTE,  *). 

APPLICABLE  ELEMENOyPE!  V AL IDAT I 0n~PATH. 

VALUE!  NUMERIC, 


ATTRIBUtE|  Max  IMUM^VALljE 

(#  THE  MAXIMUM  VALUE  A DATA  ITEM  MAY  ASSUME,  THE 
VALUE  IS  IN  THE  UNITS  STATED  IN  THE  UNITS 
ATTRIBUTE  and  should  BE  CONSISTENT  WITH  the  type  of 
THE  DATA,  *), 

APPLICABLE  ELEMENOyPE!  DATA. 

VALUE!  NUMERIC, 
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ATTRIBUTE!  MINIMUM^TIMe 

(*  THE  MINIMUM  TIME  that  can  BE  TAKEN  T 8 traverse  the 
VALIQATI8N_PATH,  THE  TIME  IS  SPECIFIED  IN  THE 
UNITS  DESIGNATED  BY  THE  UNITS  ATTRIBUTE,  *). 
APPLICABLE  FLEMENTjTYPEl  V AL  I DAT  I ON‘p  ATH'. 

VALUE ! NUMERIC. 

ATTRIBUTE!  MINIMUM 'VALUE 

(*  THE  MINIMUM  VALUE  A DATA  ITEM  MAY  ASSUME,  THE 
VALUE  IS  IN  THE  UNITS  STATED  jN  THE  UNITS 
ATTRIBUTE  and  should  BE  CONSISTENT  WITH  the  type  of 
THE  DATA,  *), 

APPLICABLE  ELEMENOyPEI  DATA, 

VALUE!  NUMERIC, 

ATTRIBUTE!  PROBLEM 

(*  THE  PROBLEM  THAT  HAS  LED  TO  ThE  NEED  FOR  A 
DECISION,  a), 

APPLICABLE  ELEMENOyPEI  DECISION, 

VALUE!  TEXT, 

ATTRIBUTE!  RANGE 

(*  THE  NAMED  VALUES  THAT  CAN  BE  ASSUMED  BY  A DATA  WITH 
TYPE  ENUMERATION,  «*)  , 

APPLICABLE  ELEMENOyPEI  DATA, 

VALUE!  TEXT 

(*  the  allowed  values  are  separated  by  commas,  *>, 

ATTRIBUTE!  RESOLUTION 

(+  DESCRIBES  THE  REQUIRED  MAXIMUM  VALUE  OF  THE  LEAST 

significant  bit  for  the  data  in  units  specified  in 

THE  UNITS  ATTRIBUTE,  *). 

APPLICABLE  ELEMENOyPEI  DATA, 

VALUE!  NUMERIC, 

ATTRIBUTE!  TEST 

(*  PROCEDURAL  COPE  (PASCAL)  WHICH  DEFINES  THE 

COMPUTATIONS  NECESSARY  TO  TEST  THE  SATISFACTION  OF 
A PERFORMANCE  requirement  using  DATA  RECORDED  by 
validation'poTnts,  the  CODE  IS  not  processed 

BY  THE  RSL  TRANSLATOR  BUT  IS  PROCESSED  BY  THE 
SIMULATION  generation  FUNCTION  and  The  COMPILER, 
a test  CONTAINS  SPECIAL  RETRIEVE  and  for  each 
OPERATIONS  TO  IDENTIFY  VALIDAtION_POjNT  RECORDINGS 
AND  MAY  USE  SELECT  AND  FOR  EACH  OPERATIONS  TO 
ACCESS  RECORDED  FILES,  *), 

APPLICABLE  ELEMENT"TYPEl  PERFORMANCE_REQuIREMENt , 

VALUE!  TEXT, 
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attribute i type 

(*  THE  TYPE  FOR  A DATA  ITEM  WHICH  IS  EITHER 

REFERENCED  ON  AN  RlNET  OR  SUBNET  OR  JS  USED  IN  A 
BETA  OR  GAMMA  SIMULATION,  *). 

APPLICABLE  ELEHENTZTYPEl  DATA, 

VALUE  I REAL. 

VALUE!  ENUMERATION 

(*  the  data  item  can  assume  only  certain  values 

WHICH  are  NAMES,  the  ALLOWED  VALUES  FqR  THE  DATA 
ITEM  ARE  SPECIFIED  IN  THE  RANGE  ATTRIBUTE,  *>, 

VALUE!  BOOLEAN, 

VALUE!  INTEGER, 

ATTRIBUTE!  UNITS 

(*  THE  ENGINEERING  UNITS  OF  THE  VALUE  Of  A DATA  ITEM 

or  the  units  in  which  the  maximumZtime  and/or 
MINIMUM.TIME  for  A VALIDATIONUPATH  are 

specified,  o, 

APPLICABLE  ELEMENOyPEI  DATA 

validationIpath'. 

VALUE!  NAMED 

C*  FOR  INDIVIDUAL  projects  IT  MAY  bE  DESIRABLE  to 

RESTRICT  THE  units  WHICH  CAN  BE  USED,  IN  THAT  CASE, 
NAMED  SHOULD  BE  REPLACED  BY  THE  SPECIFIC  LEGAL 
VALUE  NAMES,  *>, 

ATTRIBUTE!  us£ 

C*  QUALIFIES  THE  USE  OF  A DATA  ITEM  IN 
SIMULATION,  *), 

APPLICABLE  ELEMENOyPEI  DATA, 

VALUE!  BETA 

<*  THE  DATA  ITEM  Is  TO  BE  USED  IN  FUNCTIONAL 
SIMULATIONS  ONLY,  *). 

VALUE!  GAMMA 

C*  THE  DATA  ITEM  is  TO  APPEAR  in  analytic 
SIMULATIONS  ONLY,  *>. 

VALUE!  BOTH 

(*  THE  DATA  ITEM  IS  TO  BE  USED  IN  BOTH  FUNCTIONAL  AND 
ANALYTIC  SIMULATIONS,  *>, 

DATA!  CLOCOIME, 

DESCRIPTION! 

"A  PREDEFINED  DATA  ITEM  WHICH  iS  INCREMENTED  AT 
THE  SAME  RATE  AS  ENGAGEMENT  TIME,  EXCEPT  FOR  ITS 
INlTIALlVALUE  WHICH  IS  ARBITRARY,  CLOCK.TIME  may  be 
REGARDED  AS  ENGAGEMENT  TIME,  IT  HAS  nO  CLOCK 
ERROR,", 

LOcALITYi  GLOBAL, 

TYPE!  REAL. 

U N i T S t SECONDS, 

USE!  BOTH, 
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DAT  A « F5UND, 

DESCRIPTION! 

"A  predefined  DATA  ITEM  WHICH  jS  SET  t8  either 
true  or  false  after  each  select  on  an  entity'tyfe 
OR  ENTITY-JCLASS,  FOUND  IS  S' T TO  TRUf  IF  AN 
INSTANCE  satisfying  THE  SELECTION  CRITERION  is 
LOCATEDI  OTHERWISE,  FOUND  IS  ASSIGNED  THE  VALUE 
FALSE.". 

INlTIALlvALUEl  false. 

LOCALITY!  LOCAL. 

TYPE!  BOOLEAN, 

USE!  BOTH, 

DaTA!  RECORD3FOUND, 

DESCRIPTION! 

"A  PREDEFINED  DATA  ITEM  WHICH  iS  SET  yO  EITHER  TRUE 
OR  FALSE  AFTER  EACH  SELECT  ON  A FILE  jN  A BETA  OR 
GAMMA.  RECORD  FOUND  IS  SET  TO  TRUE  IF  * RECORD 
SATISFYING  THE  SELECTION  CRITERION  Is  LOCATED; 
OTHERWISE.  RECORD'FOUND  IS  ASSIGNED  ThE  VALUE 
FALSE.", 

INlTIALlvALUEl  FALSE. 

LOcALITYi  local. 

TYPE!  BOOLEAN. 

USE!  BOTH, 


D .4  SUMMARY  OF  RSL  RELATIONSHIPS  AND  ATTRIBUTES  BY  ELEMENT  TYPE 


ELEM£NT_TYPE I ALPHA 
LEGAL  RELATIONSHIPS: 

creates: 

ENTITY-CLASS 

DESTROYS: 

ENTITY-CLASS 

FORHSI 

MESSAGE 

implements: 

VERSION 

INPUTS: 

DATA 

FILE 

outputs: 

DATA 

FILE 

SETS: 

ENTITY-TYPE 
DOCUMENTED  ("BY"): 

SOURCE 

EQUATED  ("TO"): 

SYNONYM 

TRACED  ("FROM") | 

DECISION 

ORIGINATING-REQUIReMENT 
LEGAL  ATTRIBUTES! 
artificiality: 

ARTIFICIAL 

VALIDATION 

IMPLEMENT-APPROXIMaTELY 

IMPLEMENT-PRECISELY 

beta: 

TFXT 

COMPLETENESS! 

INCOMPLETE 

complete 

changeable 

DESCRIPTION! 

TEXT 

ENTERED-Byi 

TEXT 


gamma: 

TEXT 


ELEMENT-TYPE!  DATA 

LEGAL  RELATIONSHIPS! 

DELAYS! 

EVENT 

IMPLEMENTS! 

VERSION 

INCLUDES! 

OATA 

MAKES! 

MESSAGE 

ORDERS! 

FILE 

ASSOCIATED  ("WITH")! 
ENTITY-CLASS 
ENTITY-TYPE 
CONTAINED  ("IN")! 

FILE 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 

INCLUDED  ("IN")! 

DATA 

INPUT  ("TO")! 

ALf^HA 

OUTPUT  ("FROM")! 

AL^HA 

RECORDED  ("BY")! 

VALIDATIO  N— P 0 1 N T 
TRACFD  ("FROM")! 

DECISION 

ORIGINATING-REQUIREMENT 


LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement-approximately 

ImPLEMENT-PRECISELY 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

changeable 

DESCRIPTION! 

TEXT 

ENTERED-BYl 

TEXT 

INITIAL-VALUE! 

NAMED 
NUMERIC 
LOCAL  I T Y 1 
GLOBAL 
LOCAL 

MAXIHUM-VALUE! 

NUMERIC 

MINIMUM-VALUE! 

NUMERIC 

RANGE! 

TEXT 

RESOLUTION! 

NUMERIC 

TYPE! 

real 

enumeration 

BOOLEAN 

INTEGER 

UNITS! 

NAMED 

USE| 

BETA 

BOTH 

GAMMA 


ElEMENT^TYPEi  decision 
LEGAL  RELATIONSHIPS! 

IMPLEMENTS! 

VERSION 

TRaCES  («TO«)l 

alpha 

data 

DECISION 

ENTITY.CLASS 

ENTiTY.TYPE 

event 

file 

INPuTZINTERFAcE 

MESSAGE 

OUTPUT_INTERFaCE 

PERFORM ANCeZREQUIREMENT 

R_net 

subnet 

subsystem 

UNStRUCTURED.REQUIREMENT 
VALIDATION  >AtH 
VALIDATION^POINT 
VERSION 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ("TO")| 

SYNONYM 

TRACED  (*FROM«)l 
DECISION 

ORIgINATINGZREQUIREMENT 
LEGAL  ATTRIBUTES! 

ALTERNATIVES! 

TEXT 

CHOICE! 

TEXT 

COMPLETENESS! 

CHANGEABLE 

INCOMPLETE 

COMPLETE 

DESCRIPTION! 

TEXT 

ENtERED'bY! 

text 

PROBLEM! 

TEXT 
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EIEHENUTYPEI  ENTITY.CLASS 
LEGAL  RELATIONSHIPS! 
ASSOCIATES! 

DATA 

FILE 

IMPLEMENTS! 

VERSION 

COMPOSED  ("OF")i 
£NTITY*TYP£ 

CREATED  ("BY")I 
alpha 

DESTROYED  ("BY")! 

alpha 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ( "TO* ) I 
SYNONYM 

TRACFD  ("FROM")! 

DECISION 

or iginating*requi recent 

LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

artificial 

VALIDATION 

IMPLEMENT..  APPROXIMATELY 
ZMPLEMENT.PRECISELY 
COMPLETENESS! 

INCOMPLETE 

COMPLETE 

CHANGEABLE 

DESCRIPTION! 

TEXT 

ENTERED* B Y ! 

E 


ELEHENT„TYPFI  ENTITY* TYPE 
LEGAL  RELATIONSHIPS! 
ASSOCIATES! 

DATA 
FILE 
COMPOSES! 

ENTITY*CLASS 
IMPLEMENTS! 

VERSION 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 
SET  ("BY")! 

ALPHA 

TRACED  ( "FROM " ) j 
DECISION 

ORIGINATING-.REQUIREMENT 
LEGAL  ATTRIBUTES! 

ARTIF ICIALITY! 

ARTIFICIAL 
VALIDATION 

implement*appro*imately 
implement.precisely 

COMPLETENESS! 

incomplete 
complete 
changeable 

DESCRIPTION! 

TEXT 

ENTERED*BYI 

TEXT 


/ 
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EIEMENT.TYPEI  event 
LEGAL  RELATIONSHIPS  I 

enables  t 

R.NET 

IMPLEMENTS! 

VERSION 

DELAYED  ( "BY " ) I 
DATA 

DOCUMENTED  ("BY»)| 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  C"FROM")| 

DECISION 

origin at ing.requirement 

LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

IMPlemEnt.APPROXIMaTely 

IMPLEMENT.PRECISELy 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

CHANGEABLE 

DESCRIPTION! 

TEXT 

ENTERED..BYI 

TEXT 
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ELEMENT.TYPEt  file 
LEGAL  RELATIONSHIPS! 

CONTAINS! 

DATA 

IMPLEMENTS! 

VERSION 

MAKES! 

MESSAGE 

ASSOCIATED  ("WITH”) | 
entitv.class 
entity.type 

DOCUMENTED  ("BY")| 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 
INPUT  ("TO")! 

ALPHA 

ORDERED  ("BY")| 

DATA 

OUTPUT  <"FROH")| 

ALPHA 

RECORDED  ("BY")! 

valioationj»oint 

TRACED  ("FROM")! 

DECISION 

8riginating«requ i repent 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

IMRLEMENT.APPR0XIMATELY 

IMPLEMENT.PRECISELY 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

Changeable 

DESCRIPTION! 

TEXT 

ENTEPED.BY! 

TEXT 

LOCALITY! 

GLOBAL 

LOCAL 
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ELEHENT.TYPEI  INPUT.INTERFACE 
LEGAL  PEL  AT  I ONSHlpS  I 
CONNECTS  ("TO")  | 

subsystem 

ENABLES! 

r.net 

ImPLFMENTSI 

VERSION 

PASSESI 

MESSAGE 

DOCUMENTED  ("BY")i 
SOURCE 

EQUATED  <"TO")l 
Synonym 

TRACED  C"FROM")| 

decision 

ORIGINATING.REQUIREMENT 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement.approximately 

IMPLEMENT.PRECISELY 

COMPLETENESS! 

INCOMPLETE 

complete 

Changeable 

DESCRIPTION! 

TEXT 

entered.byi 

TEXT 


_ 
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ELEMENT.TYPEI  MESSAGE 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VFRSION 

DOCUMENTED  ("BY")l 
SOURCE 

EQUATED  ( "TO"  ) I 
SYNONYM 

FORMED  ( "B Y " ) I 
ALPHA 

MADE  ("BY")j 
DATA 
FILE 

PASSED  ("THROUGH")* 

input.interface 

OUTPUT.INTERFACE 
TRACED  ( "FROM " ) | 

DECISION 

ORIGINATING-REQUIReMENT 
legal  ATTRIBUTES* 

ARTIF ICIALITYJ 
ARTIFICIAL 
VALIDATION 

implement.approximately 

IMPLEMENT.PRECISELY 

COMPLETENESS! 

INCOMPLETE 

complete 

changeable 

DESCRIPTION! 

TEXT 

entered* by i 
TEXT 
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ElEMENT^TYPEi  ORIGINATING  REQUIREMENT 
LEGAL  RELATIONSHIPS! 


IMPLEMENTS! 

VERSION 

INCORPORATES! 

originatingIrequirement 

TRaCES  ("TO")! 

ALPHA 

DATA 

DECISION 

entity.class 
entity.type 
event 
PILE  . 

INPuT^INTERFACE 

MESSAGE 

OUTPUT.INTERFaCE 

perform ance^requirement 

R^NET 

subnet 

subsystem 

unstructur^d.requirement 

VALlDATIONjPATH 
VALID AT ION_POlNT 
VERSION 

DOCUMENTED  ( "BY"  ) I 
SOURCE 

EQUATED  ("TO")! 

SYNONYM 

INCORPORATED  ("IN")! 

OPIGINATINGIREQUIREMENT 
LEGAL  i - TRIBUTES! 

COMPLETENESS! 

changeable 

INCOMPLETE 

COMPLETE 

DESCRIPTION! 

TEXT 

ENtEREDIbYI 

text 
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ELEMENT.TYPEI  (5UTPUT.INTERFACE 
LEGAL  PEI  AT  I ONSHIPS  t 
CONNECTS  ( " TO  " ) I 
subsystem 
IMPLEMENTS! 

VERSION 

PASSES! 

MESSAGE 

DOCUMENTED  ("BY**)  t 
SOURCE 

EQUATED  C "TO"  ) I 
SYNONYM 

TRACED  ( "FROM"  ) | 

DECISION 

ORlGINATING_REQUIREMENT 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement.approximately 

IMPLEMENT.PRECISELY 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

changeable 

DESCRIPTION! 

TFXT 

ENTEPED^BYI 

TEXT 


ElEMENT^TYPE!  performance  requirement 
UEGAl  RELATIONSHIPS! 

CONSTRAINS! 

validation^path 
IMPLEMENTS! 

VERSION 

DOCUMENTED  (H8Y")I 
SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  C«FR0M»)| 

DECISION 

origin at ing~requirement 

LEGAl  ATTRIBUTES! 

COMPLETENESS! 

changeable 
incomplete 

COMPLETE 
DESCRIPTION! 

TEXT 

ENtEREDIbY! 

TEXT 

TEST! 

TEXT 

ii 


r i 


ELEMENT.TYPEI  r„net 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

DOCUMENTED  ("BY")! 

SOURCE 

ENABLED  ("BY")! 

EVENT 

input.interpace 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ("FROM")! 

DECISION 

ORIGINATING.REQUIRE^ENT 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement.approximately 

IMPLEMENT.PRECISELY 

COMPLETENESS! 

INCOMPLETE 

complete 

CHANGEABLE 

DESCRIPTION! 

TEXT 

entered.byi 

TEXT 

LEGAL  STRUCTURE  ELEMENT.TyPESi 
ALPHA 
EVENT 

input.intereace 

OUTPDT.INTERFACE 

subnet 

VALIDATION..POINT 
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El'EMENT3|TYPEi  source 
LEGAL  RELATIONSHIPS! 

DOCUMENTS! 

alpha 

data 

DECISION 

entity.class 

entity.type 

event 

file 

INPuTllNTERFACE 

message 

ORIGINATING^REQUIREMENT 

OUTPUT.INTERFaCE 

PERFORMANCE~‘REQUlREMENT 

R.NET 

subnet 

SUBSYSTEM 

UNSTRUCTURED_REQUIREMENT 

validation“path 

validatibnj>oint 

VERSION 

EQUATED  rTO")! 

SYNONYM 

LEGAL  ATTRIBUTES! 

COMPLETENESS! 

changeable 

INCOMPLETE 

COMPLETE 

DESCRIPTION! 

TEXT 

entered“byi 

TEXT 
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f 


ELEM£NT_TYPEi  subnet 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

DOCUMENTED  ( "BY " ) I 
SOURCE 

EQUATED  ("TO") ! 

SYNONYM 

TRACED  ("EROM")| 

DECISION 

OP  I GJ  NAT  INC..  RE  QUIRE  PENT 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

IMPLEMENT.APPROXIMaTELY 

IMPLEMENT.PRECISELY 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

changeable 

DESCRIPTION! 

TFXT 

ENTEREP.BYI 

TEXT 

LEGAL  STRUCTURE  ELEMENT„TyPES | 
ALPHA 
EVENT 

output.interface 

subnft 

VALIDATION.POINT 
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ELEMENTi^TYPEl  subsystem 
LEGAL  RELATIONSHIPS! 


IMPLEMENTS! 

VERSION 

CONNECTED  ("TO")l 

inputIjnterface 

output.interface 

DOCUMENTED  <"BY»)I 
SOURCE 

EQUATED  f"TO")l 
SYNONYM 

TRaCEO  ( "FROM" J | 

DECISION 

originatingIrequirement 

LEGAL  ATTRIBUTES! 

COMPLETENESS! 

CHANGEABLE 

incomplete 

complete 

DESCRIPTION! 

TEXT 

ENtEREDIbYI 

text 
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EIE*ENT„TYDF I SYNPNY* 

LEGAL  RELATIONSHIPS! 

EQUATES  ("T9" ) I 
alpha 

DATA 

DECISION! 

entity_cl*ss 

ENTITY..TYPE 

EVENT 

FILE 

input.interface 

message 

ORIGINATING.REQ'iibpvenT 

OLITPUT.INTERFACE 

PEHFORMANCE«.P£DUIPEMfNT 

R„NET 

SOURCE 

subnet 

subsystem 

UNSTRUCTURED-REQUIREMENT 

VALIDATION.PATH 

VALIPATIPN.POINT 

VERSION 

NO  LEGAL  ATTRIBUTES 


D-49 


element  ?jtype}  unstrijctured^requirement 

LEGAL  RELATIONSHIPS} 

IMpLEMENYSl 

VERSION 

DOCUMENTED  ("BY") I 
SOURCE 

EQUATED  ( " T 0 11 ) | 

SYNONYM 

TRACED  («CROM«)l 
DECISION 

ORIBINATInOeQUIRF-MENT 
LEGAL  ATTRIBUTES} 

COMPLETENESS} 

CHANGEABLE 

INCOMPLETE 

COMPLETE 

DESCRIPTION} 

TEXT 

ENtEREDIhY} 

TEXT 


■P 


I 

ELEM£NT_TYPEl  VALI0ATI8N.PATH 
LEGAL  RELATIONSHIPS! 

IMPLEMENTS! 

VERSION 

CONSTRAINED  ("By")! 

PERP ORM A NCE— REQUIREMENT 

documented  ("BY")! 

SOURCE 

EQUATED  ("TO" ) I 
SYNONYM 

TRACEO  ( "FROM " ) | 

DECISION 

OR1GINATING.REQUIREMENT 
LEGAL  ATTRIBUTES! 

ARTIFICIALITY! 

ARTIFICIAL 
VALIDATION 

IMPLEMENT.APPROXIMaTELY 
IMPLEMENT.PRECISELY 
COMPLETENESS! 

INCOMPLETE 
COMPLETE 
CHANGEABLE 
DESCRIPTION! 

TEXT 

entered.byi 

TEXT 

MAXIMUM„TIMEl 
NUMERIC 
MINIMUM.TIME! 

NUMERIC 
UNITS! 

NAMED 

LEGAL  PATH  ELEMENT.TYPESl 
EVENT 

validation.point 


L 
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ELEMENT^TVPEI  VALIDATION.POINT 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

RECORDS! 

DATA 

FILE 

DOCUMENTED  ("BV")| 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ("FROM")! 

DECISION 

originating.requirement 
legal  attributes; 

ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

Implement_appro*imately 
implement. precisely 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

changeable 

DESCRIPTION! 

TEXT 

ENTEPED..BYI 

TEXT 


ElEMENT«TYPE|  version 
legal  RELATIONSHIPS! 

DOCUMENTED  <"6Y«)i 
SOURCE 

EQUATED  ("TO")  I 
SYNONYM 

IMPLEMENTED  (»BY")| 

ALPHA 

DATA 

DECISION 

entity.class 
entity.type 
event 
file  _ 

INPuT.INTERFACE 

MESSAGE 

ORIGINATING^REQUIREMENT 

OUTPUT.INTERFACE 

PERFORMANCElREQUlREMENT 

r:net 

SUBNET 

subsystem 

UNSTRUCTURED.REQUIREMENT 
VALlDAT!ON“PATH 
VALlDATIONj»OlNT 
TRACED  ("FROM")! 

DECISION 

ORIcINATINgZREQUIREMENT 
LEGAL  ATTRIBUTES! 

COMPLETENESS! 

CHANGEABLE 

INCOMPLETE 

COMPLETE 

DESCRIPTION! 

TEXT 

entered“byi 

text 


D.5  RSL  TRANSLATION  DIAGNOSTIC  MESSAGES 


Diagnostics  from  the  RSL  translation  function  are  printed  as  an  up- 
arrow  ( + ) pointing  to  the  command  symbol  at  which  the  error  was  first 
detected  and  an  error  number.  The  error  may  be  detected  one  or  more 
symbols  beyond  the  actual  error. 

When  an  error  occurs  in  the  first  sentence  of  a command  ( 1 . e . , the 
sentence  which  identifies  the  subject  element),  the  results  are  difficult 
to  predict.  The  translator  may  not  recognize  the  sentence  as  beginning 
a new  command,  will  ignore  the  sentence  and  proceed  to  apply  the  succeeding 
sentences  to  the  previous  subject  element  as  though  no  new  command  had 
begun. 

Whenever  a syntax  error  is  detected  (error  numbers  12-199),  all  input 
text  between  the  detection  of  the  syntax  error  and  the  recovery  from  that 
error  (error  number  200)  is  ignored.  No  attempt  is  made  to  check  the  syntax 
of  this  text  nor  are  any  actions  performed  on  the  ASSM. 

The  diagnostics  output  during  RSL  translation  are  listed  below. 

(This  list  also  contains  the  diagnostics  for  the  RSL  Extension  (RSLXTND) 
function.)  The  majority  of  the  errors  will  cause  the  sentence  to  be  Ignored 
(i.e.,  no  action  will  be  taken  in  the  ASSM).  Those  marked  with  (I)  are  in- 
formative only;  the  action  specified  In  the  command  will  be  taken.  Those 
marked  with  (F)  will  cause  termination  of  translation  and  the  return  of 
control  to  the  REVS  Executive. 

Error 

No . Interpretation 

0 The  parse  stack  is  not  empty  at  the  end  of  the  translation.  (This 
usually  Indicates  a severe  syntax  error.)  (F) 

1 Parse  stack  overflow.  Reduce  the  complexity  of  the  statement.  (F) 

5 Illegal  character  or  illegal  two-character  operator. 

6 Integer  too  large  (i.e.,  larger  than  9 digits). 

7 Too  many  significant  figures  in  a real  number  (I.e.,  more  than 
9 digits). 

8 Real  number  too  large  (i.e.,  absolute  value  greater  than  1.0E74). 

11  More  than  50  errors  in  one  lir 
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Error 

No. 


Interpretation 
12-199  Syntax  Error. 

200  Recovery  from  previous  syntax  error.  (I) 

201  A comment  was  expected.  (I) 

202  Comment  not  allowed  here.  (I) 

203  A period  is  missing  at  the  end  of  the  input  file.  (I) 

204  Duplicate  relationship  instance  in  the  ASSM.  (I) 

400  An  instance  of  this  attribute  already  exists. 

401  The  element  type  is  not  an  applicable  element  type  for  this 

attribute. 

402  The  given  element  is  associated  with  a node  of  a STRUCTURE  or 
PATH. 

403  The  element  type  is  an  applicable  element  type  for  an  attribute. 

404  Illegal  sentence  in  an  attribute  definition. 

405  Attribute  definition  sentence  misplaced. 

406  OR  node  ordinal  exceeds  maximum  of  9999. 

407  Error  in  a conditional  expression. 

408  Complementary  relation  name  is  used  in  a relation  definition 
header. 

409  Element  is  not  of  type  DATA. 

410  Degenerate  logical  or  arithmetic  expression. 

411  Sentence  appears  after  a deletion  command. 

413  Duplicate  attribute  instance. 

414  Duplicate  definition  for  an  attribute  name. 

415  Element  type  is  already  in  the  ASSM. 

416  Duplicate  element  type  list  member. 

417  Duplicate  NET/PATH  structure  applicability. 

418  Duplicate  ordinals  on  two  branches  of  the  same  OR  node. 


, 
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Error 

No.  Interpretation 

419  Duplicate  definition  for  a relation  name. 

421  Duplicate  relation  object  on  object  list. 

422  Element  already  has  an  associated  STRUCTURE  or  PATH. 

423  Duplicate  attribute  legal  value.  (I) 

424  Illegal  sentence  in  element  definition. 

425  Element  definition  sentence  misplaced. 

426  An  element  exists  with  this  element  type. 

427  Node  element  is  not  of  a type  defined  with  structure  applicability 
NET. 

428  Illegal  sentence  in  an  element  type  definition. 

429  An  element  of  the  given  type  is  used  on  a NET  or  PATH. 

430  Element  type  definition  sentence  misplaced. 

431  "RECORD"  must  be  preceded  by  FILE  name. 

432  Element  name  In  the  body  of  a FOR  EACH  node  Is  not  of  type  ALPHA 
or  SUBNET. 

433  Element  Is  not  of  type  FILE,  ENTITY_TYPE,  or  ENTITY_CLASS. 

434  Illegal  syntax  following  DO. 

435  An  INPUT_INTERFACE  begins  a branch. 

436  An  INPUT_INTERFACE  follows  a node. 

437  Illegal  value  for  this  attribute. 

438  Illegal  complementary  relation  name  for  this  relation. 

439  A declaration  removal  must  be  within  a modification  command. 

440  Name  being  renamed  is  not  an  element  name. 

441  Illegal  object  element  type  for  a relation. 

442  Illegal  subject  element  type  for  a relation. 

443  Element  type  name  is  incorrect  for  the  element. 

444  Invalid  attribute  name. 
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Error 

No. 


445 

446 

447 

448 


449 

450 

451 


452 

453 

454 

455 

456 

457 

458 

459 

460 

461 

462 

463 

464 

465 


466 

467 


Interpretation 
Invalid  element  name. 

Invalid  element  type  name. 

Invalid  relation  name. 

Too  many  new  (undefined)  names.  (This  error  should  be  ignored 
between  a syntax  error  (12-199)  and  the  recovery  from  that 
error  (200).) 

Name  already  in  use. 

A node  follows  a terminator  node  or  OUTPUT_INTERFACE. 

New  (undefined)  name  was  lost.  (This  error  should  be  ignored 
between  a syntax  error  (12-199)  and  the  recovery  from  that 
error  (200).) 

The  ALL  EXCEPT  form  may  not  be  used  for  removals. 

No  instance  of  this  attribute  exists  for  the  given  element. 

Given  attribute  legal  value  does  not  exist. 

No  object  list  in  a relation  declaration. 

A node  is  not  allowed  in  a structure  removal. 

Element  type  has  no  NET/PATH  structure  applicability. 

Element  does  not  have  an  associated  PATH. 

The  given  relationship  instance  does  not  exist. 

Element  does  not  have  an  associated  STRUCTURE. 

No  type  specified  for  undefined  element. 

No  valid  subject  for  the  command. 

No  element  type  list  is  specified. 

An  attribute  value  is  not  specified. 

Element  is  the  object  of  a relation  instance,  therefore  it  cannot 
be  deleted. 

Ordinal  and  non-ordinal  branches  are  mixed  in  an  OR  node. 

Illegal  sentence  in  relation  definition. 


D-58 
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Error 

No. 

468 

469 

470 

471 

472 

473 

474 

475 

476 

477 

478 

479 

480 

481 

482 

483 

484 

485 

486 

487 

488 

489 




Interpretation 

Relation  definition  sentence  misplaced. 

A RETURN  may  not  appear  on  an  R_NET. 

An  instance  of  this  relationship  exists. 

The  element  type  is  a legal  object  element  type  of  a relationship, 
therefore  the  element  type  definition  cannot  be  deleted. 

The  element  type  is  a legal  subject  element  type  of  a relationship, 
therefore  the  element  type  definition  cannot  be  deleted. 

Structure  has  fewer  than  two  nodes. 

Structure  has  no  terminator  node  or  OUTPUT_INTERFACE. 

Command  subject  is  not  of  type  R_NET  or  SUBNET  so  a structure 
declaration  is  illegal . 

Element  is  the  subject  of  a relation  instance,  and  cannot  be 
deleted. 

The  given  SYNONYM  already  EQUATES  to  an  element. 

Terminating  and  non-terminating  branches  are  mixed  within  an 
AND/OR  node. 

Name  is  undefined. 

Node  element  is  not  of  a type  defined  with  structure  applicability 
PATH. 

Command  subject  is  not  of  type  VALIDATION_PATH,  so  PATH  declara- 
tion is  illegal . 

An  attribute  value  is  specified  where  none  is  allowed.  (I) 

A node  is  not  allowed  in  a PATH  removal. 

PATH  has  no  nodes. 

Zero  ordinal . 

Element  is  not  of  type  ENTITY_TYPE  or  ENTITY_CLASS. 

New  type  is  redundant  on  a RETYPE. 

An  INPUT  INTERFACE  is  illegal  on  a SUBNET. 

SUBNET  has  no  RETURN. 
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Error 

No. 


Interpretation 


SUBNET  has  more  than  one  RETURN. 


RETYPE  of  an  OUTPUT  INTERFACE  which  appears  on  a structure  is 
illegal . 

Element  is  not  of  type  DATA  or  ENTITY_CLASS. 

Element  has  a value  for  TYPE  other  than  ENUMERATION. 

Element  is  not  of  type  ENTITY_TYPE. 

Enumerated  value  name  required. 

Permission  to  use  extensions  not  established. 

Control  permission  required  but  not  established. 

A permission  is  already  associated  with  the  identifier. 

No  permission  is  associated  with  the  identifier. 

Translator  was  not  invoked  via  RSLXTND. 

Last  control  permission  cannot  be  rescinded  with  outstanding 
extension  permissions. 

Extension  permission  cannot  be  established  without  any  control 
permissions. 

No  non-empty  branch  on  a CONSIDER  OR  node. 

More  than  one  empty  branch  on  a CONSIDER  OR  node. 

Duplicate  name  in  consider  conditional. 

Comma,  colon,  or  semicolon  in  conditional  expression. 

Name  reserved  by  ASSM.  (F) 

Error  In  initialization.  (F) 

Error  in  REVS  Executive  request.  (F) 

Error  In  ASSM  access  routine.  (F) 

Required  input  file  DONNEES  is  missing  or  empty.  (F) 

Required  input  file  RSLDICT  Is  missing,  empty,  or  Incomplete.  (F) 
Null  ASSM,  RSLXTND  required  for  language  definition.  (F) 
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RNETGEN  MESSAGES 

A DANGLING  STRUCTURE  HAS  BEEN  DETECTED,  SAVE  REJECTED 

This  message  results  when,  in  an  attempt  to  save  a structure,  an 
incomplete  structure  was  detected,  i.e.,  a node  with  no  predecessor 
or  successor.  The  structure  is  displayed  with  the  node  in  question 
located  at  the  center  of  the  structure  display  area  surrounded  by  a 
red,  blue,  and  white  square.  The  structure  remains  In  the  ASSM  In 
temporary  status. 

A DO-NOTHING  BRANCH  DETECTED  ON  REJOINING  AND,  SAVE  REJECTED 

This  message  results  when,  in  an  attempt  to  save  a structure,  a 
null  AND  branch  was  detected,  i.e.,  the  successor  node  of  an  AND 
node  is  its  matching  rejoining  AND  node.  The  structure  is  dis- 
played with  the  AND  node  in  question  centered  in  the  structure 
display  area  surrounded  by  a red,  blue,  and  white  square.  The 
structure  remains  In  temporary  status  In  the  ASSM. 

CALCOMP  REQUEST  COMPLETED,  CONTINUE 

This  message  is  displayed  upon  completion  of  a CALCOMP  menu  opera- 
tion. The  message  informs  the  user  that  the  selected  structure 
has  been  successfully  plotted  on  CALCOMP  and  that  further  pro- 
cessing may  now  continue. 

CANNOT  EXECUTE  RNETGEN  FUNCTION  IN  OFFLINE  MODE 

This  message  will  appear  on  REVS. OUT  if  the  user  attempts  to 
execute  the  RNETGEN  function  while  in  the  off-line  mode.  RNETGEN 
terminates  and  returns  control  to  the  REVS  Executive. 

COLOR  HAD  BEEN  CHANGED  ON  SELECTED  NODE,  CONTINUE 

This  message  is  displayed  merely  to  inform  the  user  that  the  node 
color-change  operation  is  complete  and  that  further  processing  may 
now  continue. 

COMMENT  HAS  BEEN  ATTACHED  TO  SELECTED  NODE,  CONTINUE 

This  message  is  displayed  upon  completion  of  a connent  node  menu 
operation.  The  message  informs  the  user  that  the  comment  was 
successfully  attached  to  the  node  in  the  ASSM  and  that  further 
processing  may  now  continue. 

COMMENT  MUST  BEGIN  WITH  (*,  INPUT  REJECTED 

This  message  results  when  an  attempt  to  enter  a comment  which 
does  not  begin  with  the  character  string  (*  Is  made.  The  Input 
is  rejected,  however  the  comment  node  menu  selection  remains  in 
force. 
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COMMENT  WAS  REMOVED,  IF  INDEED,  ONE  EXISTED 

This  message  results  from  the  REMOVE  comment  operation.  It  is  in- 
tended to  inform  the  user  that  the  selected  operation  is  complete 
and  that  other  processing  may  now  continue. 

CONSIDER  - DATA,  ENTITY_CLASS,  NEITHER  - SELECT  VIA  TRACKBALL 

This  message  is  displayed  after  having  selected  the  point  on  the 
screen  to  locate  an  OR  node.  The  user  must  respond  by  selecting 
one  of  the  entries  In  the  message  using  the  trackball. 

DISPLAY  BRANCH  IS  COMPLETE,  CONTINUE 

This  message  Is  displayed  merely  to  inform  the  user  that  the  opera 
tion  Is  complete  and  that  further  processing  may  now  continue. 

DO  YOU  WANT  STANDARD  DOCUMENT  SIZE?  KEYIN  YES  OR  NO 

This  message  is  displayed  when  the  user  selects  the  CALCOMP  menu 
entry.  The  keyboard  is  enabled  and  the  user  must  respond  with  a 
YES  (Y)  or  NO  (N)  keyboard  entry.  If  the  response  Is  YES,  the 
CALCOMP  display  will  be  8-1/2  x 11  Inch  document  size,  otherwise 
the  user  will  be  required  to  supply  the  desired  document  size. 

DOES  BRANCH  HAVE  CONDITIONAL  EXPRESSION?  KEYIN  YES  OR  NO 

This  message  is  displayed  when  an  attempt  Is  made  to  connect  a 
FOR  EACH  node  with  its  successor  node.  The  keyboard  Is  enabled 
and  the  user  must  respond  with  a YES  (Y)  or  NO  (N)  keyboard  entry. 
If  the  response  is  YES,  the  user  will  be  required  to  enter  the 
conditional  expression  via  the  keyboard. 

DOES  BRANCH  HAVE  ORDINAL  VALUE?  KEYIN  YES  OR  NO 

This  message  is  displayed  when  an  attempt  is  made  to  create  the 
initial  branch  of  an  OR  node.  The  keyboard  is  enabled  and  the 
user  is  required  to  respond  with  a YES  (Y)  or  NO  (N)  keyboard 
entry.  If  the  response  is  YES,  the  user  will  be  required  to 
enter  the  ordinal  value. 

DUPLICATE  ORDINAL,  INPUT  REJECTED,  ENTER  TB  TO  CONTINUE 

This  message  results  if  there  already  exists  a branch  from  the 
current  OR  node  which  has  an  ordinal  value  equal  to  the  one  which 
was  just  input.  The  ordinal  input  is  rejected  and  the  user  is 
required  to  re-input  a different  ordinal  value. 

ELEMENT  ALREADY  IN  ASSM.  IS  IT  THE  ONE?  KEYIN  YES  OR  NO 

This  message  results  when  the  element  name  keyed-in  by  the  user  Is 
already  in  the  ASSM  and  its  type  agrees  with  that  reflected  by 
the  menu  selection.  The  keyboard  is  enabled  and  the  user  is  re- 
quired to  respond  with  YES  or  NO.  If  the  response  Is  YES  and  the 
menu  selection  was  a structure  type,  the  structure,  if  one  exists, 
is  retrieved  from  the  ASSM  and  displayed  In  the  structure  display 
area.  If  the  response  is  YES  and  the  menu  selection  was  a node 
type,  the  node  is  displayed  at  the  selected  position  in  the 
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structure  display  area.  The  first  three  characters  of  the  asso- 
ciated element  name  is  also  displayed  on  the  node.  If  the  response 
is  NO,  the  element  name  which  was  keyed-in  is  ignored  and  the  current 
menu  selection  remains  in  force. 


ELEMENT  HAS  BEEN  ENTERED  INTO  ASSM 

If  the  user  responded  with  a YES  to  the  previous  message  (i.e., 

ELEMENT  NOT  IN  ASSM.  DO  YOU  WANT  IT  ENTERED?  KEYIN  YES  OR  NO), 
the  element  is  entered  into  the  ASSM  and  the  above  message  is 
displayed. 

ELEMENT  HAS  NOT  BEEN  ENTERED  INTO  ASSM 

If  the  user  responded  with  a NO  to  the  previous  message  (I.e., 

ELEMENT  NOT  IN  ASSM.  DO  YOU  WANT  IT  ENTERED?  KEYIN  YES  OR  NO), 
then  the  element  is  not  entered  into  the  ASSM  and  the  input  Is 
ignored;  however,  the  current  menu  selection  remains  in  force. 

ELEMENT  HAS  TYPE  OTHER  THAN  ENUMERATION,  INPUT  REJECTED 

If  element  type  DATA  was  selected  for  the  CONSIDER  OR  node  and 
the  supplied  element  name  has  the  attribute  TYPE  with  a value 
other  than  ENUMERATION,  this  message  is  displayed.  The  element 
name  is  ignored  and  the  node  screen  position  must  be  reselected 
by  the  user. 

ELEMENT  IN  EXPRESSION  IS  OF  INCORRECT  TYPE,  INPUT  REJECTED 

If  the  conditional  expression  keyed-in  for  an  OR/FOR  EACH  branch 
contains  ASSM  elements  of  element  type  other  than  DATA,  then  this 
message  results.  The  desired  branch  connection  is  ignored  and 
the  user  must  again  identify  the  nodes  to  be  connected  and  re-input 
the  conditional  expression. 

ELEMENT  IS  IN  ASSM  AND  IS  OF  INCOMPATIBLE  TYPE,  INPUT  REJECTED 

This  message  results  when  the  element  name  keyed-in  by  the  user  is 
already  in  the  ASSM  and  its  type  does  not  agree  with  that  reflected 
by  the  menu  selection.  The  input  is  rejected  and  the  current  menu 
selection  remains  in  force. 

ELEMENT  NOT  IN  ASSM.  DO  YOU  WANT  IT  ENTERED?  KEYIN  YES  OR  NO 

This  message  results  if  the  element  name  keyed-in  does  not 
currently  exist  in  the  ASSM.  The  user  must  respond  via  the  key- 
board with  either  YES  (Y)  or  NO  (N). 

EL EMENT_TYPE  DOES  NOT  EXIST  IN  THE  ASSM,  INPUT  REJECTED 

This  message  results  if  an  element  type  keyed-in  by  the  user 
cannot  be  found  in  the  ASSM.  The  menu  selection  is  ignored. 

ELEMENTJYPE  UNDEFINED  FOR  THIS  NODE  TYPE,  INPUT  REJECTED 

This  message  results  when,  in  an  attempt  to  enter  a node  for  a 
selected  node  type,  it  Is  determined  that  there  exists  no  defini- 
tion in  the  ASSM  for  such  an  element.  For  instance,  if  an  attempt 
to  enter  an  alpha  node  is  made  but  there  exists  no  element  type  ALPHA 
in  the  ASSM  the  above  message  is  displayed  and  the  request  is  ignored. 
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ENTER  COMMENT  SEGMENT 


This  message  is  displayed  when  in  the  comment  node  menu  opera- 
tion and  a node  has  been  selected  to  comment.  The  keyboard  is 
enabled  and  the  user  must  keyin  a comment  line.  The  entire  com- 
„ ment  must  be  enclosed  with  (*  and  *). 

ENTER  CONDITIONAL  EXPRESSION  SEGMENT 

This  message  is  displayed  when  attempting  to  connect  an  OR/FOR  EACH 
node  with  its  successor.  The  keyboard  is  enabled  and  the  user  must 
keyin  the  desired  conditional  expression.  The  entire  expression 
must  be  enclosed  within  parentheses,  except  for  an  OTHERWISE 
expression. 

ENTER  DESIRED  ELEMENT_TYPE  VIA  THE  KEYBOARD 

If  the  user  has  selected  a node  type  of  OTHER  in  the  menu,  the  above 
message  is  displayed.  The  user  responds  with  a keyboard  entry  of 
the  appropriate  element  type. 

ENTER,  REMOVE,  OR  DISPLAY  COMMENT  ON  NODE,  SELECT  VIA  TB 

This  message  results  from  the  selection  of  a node  after  having 
selected  the  comment  node  menu  operation.  The  user  must  respond 
with  a trackball  selection  of  the  desired  operation  within  the 
displayed  message. 

ENTIRE  COMMENT  ON  SELECTED  NODE  HAS  BEEN  DISPLAYED 

This  message  is  displayed  merely  to  inform  the  user  that  the 
display  comment  operation  is  complete  for  the  selected  node. 

ERROR  IN  INPUT,  TRY  AGAIN 

This  message  results  when  a non-numeric  value  is  Input  as  a 
CALCOMP  document  size.  The  input  is  Ignored  and  the  keyboard 
is  re-enabled  for  input. 

FOR  EACH  - FILE,  ENTITY_CLASS,  ENTITYJYPE  - SELECT  VIA  TB 

This  message  is  displayed  when  a FOR  EACH  node  is  entered  on  a 
structure.  The  trackball  is  enabled  and  the  user  must  respond 
with  a trackball  selection  of  one  of  the  three  entries  in  the 
message  In  order  to  designate  the  element  type  for  the  element 
associated  with  the  FOR  EACH  node. 

ILLEGAL  MENU  SELECTION 

This  message  will  result  if  an  attempt  Is  made  to  zoom-in  on  a 
structure  which  is  not  in  the  zoomed-out  mode,  i.e.,  the  structure 
has  not  first  been  zoomed-out.  The  message  will  also  occur  If 
an  attempt  is  made  to  process  a structure  which  is  non-existent. 
Selection  is  ignored. 
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ILLEGAL  NODE  FOR  CURRENT  STRUCTURE 


This  message  is  displayed  if  an  attempt  is  made  to  enter  a node 
which  is  not  allowed  for  the  current  structure  type  (e.g.,  a return 
node  on  an  R-Net  structure  is  illegal).  Another  menu  selection 
should  be  made  at  this  point. 

ILLEGAL  NODE  SELECTION,  RESTART  SELECTION  SEQUENCE 

This  message  may  result  for  several  different  reasons  as  follows: 

(a)  an  attempt  to  delete  a node  which  has  successors  which  have 
no  graphics  coordinate  data. 

(b)  an  attempt  to  disconnect  nodes  which  are  not  actually  con- 
nected. 

(c)  an  attempt  to  connect  nodes  which  cannot  be  legally  con- 
nected. 

The  selection  sequence  is  ignored,  however  the  current  menu  selec- 
tion remains  in  force. 

ILLEGAL  ORDINAL  VALUE,  INPUT  REJECTED,  ENTER  TB  TO  CONTINUE 

This  message  results  if  an  attempt  is  made  to  input  an  ordinal 
value  whose  characters  are  not  numeric.  The  input  is  rejected 
and  the  user  is  required  to  re-input  the  ordinal  value  correctly 
via  the  keyboard. 

ILLEGAL  REJOINING  AND/OR  NODE,  SAVE  REJECTED 

This  message  results  when,  in  an  attempt  to  save  a structure, 
either  an  unmatched  rejoining  AND/OR  node  was  detected  or  an 
attempt  to  mix  splitting  and  rejoining  branches  from  the  same  OR 
node  was  detected.  In  either  case,  the  structure  is  displayed 
with  the  node  in  question  centered  in  the  structure  display  area 
surrounded  by  a red,  blue,  and  white  square.  The  structure 
remains  In  the  ASSM  In  temporary  status. 

ILLEGAL  SUCCESSOR  NODE,  RESTART  SELECTION  SEQUENCE 

This  message  will  result  if,  when  attempting  to  connect  two  nodes, 
it  has  been  determined  that  the  desired  successor  node  cannot 
legally  follow  the  selected  predecessor  node.  The  desired  con- 
nection is  ignored,  however,  the  current  menu  selection  remains 
in  force  (i.e.,  the  user  may  reselect  two  nodes). 

ILLEGAL  SYNTAX,  INPUT  REJECTED 

This  message  results  if  the  ASSM  element  name  typed  in  via  the 
keyboard  contains  illegal  characters  or  does  not  begin  with  an 
alphabetic  character.  The  message  also  results  if  the  syntax  for 
the  CONSIDER  OR  node  conditional  expression  is  in  error. 

ILLEGAL  TRACKBALL  SELECTION 

This  message  will  result  if  the  user  selects  a point  on  the  screen 
outside  the  structure  display  area  when  indeed  the  selected  point 
should  be  within  the  structure  display  area.  The  input  is  ignored, 
however  the  current  menu  selection  remains  in  force. 
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IS  PREDECESSOR  NODE  A REJOINING  -OR-  NODE,  KEYIN  YES  OR  NO 

This  message  is  displayed  when  the  predecessor  node  of  two  nodes 
to  be  connected  is  an  OR  node  and  no  implicit  determination  can 
be  made  as  to  its  type  — rejoining  or  non-rejoining  OR  node. 

The  keyboard  is  enabled  and  the  user  must  respond  with  a YES  (Y) 
or  NO  (N)  keyboard  entry. 

IS  THIS  A REJOINING  -OR/AND-  NODE? 

This  message  is  displayed  when  the  user  attempts  the  comment  node 
menu  operation  on  an  OR/AND  node.  The  user  must  respond  by 
typing  in  YES  (Y)  or  NO  (N)  via  the  keyboard.  If  the  response  Is 
YES  (Y)  the  operation  will  be  ignored. 

KEYIN  DOCUMENT  HEIGHT  (INCHES) 

This  message  follows  a request  for  entry  of  the  document  width  when 
the  user  chooses  not  to  use  standard  document  size  for  CALCOMP 
output.  The  keyboard  is  enabled  and  the  user  inputs  a one  to  four 
digit  number  (real  or  integer)  to  be  used  for  the  height  of  the 
JU.C0MP  output.  Any  number  larger  than  29.0  will  be  reduced  to 
29.0. 

KEYIN  DOCUMENT  WIDTH  (INCHES) 

The  message  results  if  the  user  chooses  not  to  use  standard 
document  size  for  CALCOMP  output.  The  keyboard  is  enabled  and  the 
user  inputs  a one  to  four  digit  number  (integer  or  real)  to  be 
used  for  the  width  of  the  CALCOMP  output.  Any  number  larger  than 
50.0  will  be  set  to  50.0. 

KEYIN  ELEMENT  NAME  OF  DESIRED  ELEMENT 

This  message  is  displayed  when  the  user  selects  a structure  type 
or  when  the  user  selects  a screen  position  In  the  structure  dis- 
play area  after  having  selected  the  desired  node  type.  The  key- 
board is  enabled  and  the  user  is  required  to  enter  the  element 
name  of  the  desired  element. 

KEYIN  ENTITY_TYPE  ELEMENT (S)  ASSOCIATED  WITH  THIS  BRANCH  ( ) 

This  message  Is  displayed  when  the  user  attempts  to  connect  a 
CONSIDER  OR  node  with  Its  successor.  The  CONSIDER  OR  node  Is 
associated  with  an  ASSM  element  of  type  ENTITY_CLASS.  The  user 
responds  by  typing  in  the  ENTITY_TYPE  element(s)  associated  with 
the  selected  branch. 

KEYIN  ORDINAL  VALUE 

This  message  is  displayed  when,  in  creating  a branch  of  an  OR 
node,  it  has  been  determined  that  an  ordinal  value  Is  required. 

The  keyboard  is  enabled  and  the  user  must  respond  with  a one  to 
four  digit  keyboard  entry. 
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KEYIN  RANGE  VALUE(S)  ASSOCIATED  WITH  THIS  BRANCH  ( ) 

This  message  is  displayed  when  the  user  attempts  to  connect  a 
CONSIDER  OR  node  with  its  successor.  The  CONSIDER  OR  node  is 
associated  with  an  ASSM  element  of  type  DATA.  The  user  responds 
by  typing  in  the  RANGE  values  associated  with  the  selected  branch. 

LOOP  DETECTED  IN  THE  STRUCTURE,  SAVE  REJECTED 

This  message  results  when,  in  an  attempt  to  save  a structure,  a 
loop  was  detected  by  the  structure  analyzer.  The  structure  is 
displayed  with  the  node  in  question  centered  in  the  structure 
display  area  surrounded  by  a red,  blue,  and  white  square.  The 
structure  remains  In  the  ASSM  in  temporary  status. 

MOVE  HAS  BEEN  COMPLETED,  CONTINUE 

This  message  is  displayed  upon  completion  of  a move  node  menu 
operation.  The  message  is  intended  to  inform  the  user  that  the 
node  was  successfully  moved  to  its  new  screen  position,  and  that 
further  processing  may  now  continue. 

MOVE  SUBTREE  OPERATION  IS  COMPLETE,  CONTINUE 

This  message  is  displayed  upon  completion  of  the  move  subtree  menu 
operation.  The  message  informs  the  user  that  the  move  subtree 
operation  was  successfully  completed  and  that  further  processing 
may  now  continue. 

NAME  ALREADY  IN  ASSM  AS  SOME  OTHER  RSL  NAME,  NODE  REJECTED 

This  message  results  when  an  element  name  keyed  in  by  the  user 
already  exists  in  the  ASSM  for  some  other  use  such  as  relationship 
name,  attribute  name,  etc.  The  input  is  ignored;  however,  the 
current  menu  selection  remains  in  force. 

NO  COMMENT  EXISTS  ON  SELECTED  NODE,  REQUEST  IGNORED 

If  the  user  has  selected  a node  which  contains  no  comments  for 
display,  the  above  message  is  displayed. 

NO  CONDITIONAL  EXPRESSION  ON  THIS  BRANCH 

This  message  results  if,  after  having  selected  the  display  branch 
menu  operation,  the  selected  branch  contains  no  conditional  expres 
sion.  The  input  is  then  rejected. 

NO  CURRENT  STRUCTURE  ASSOCIATED  WITH  ELEMENT 

This  message  results  when  an  attempt  Is  made  to  display  the  struc- 
ture for  an  element  selected  by  the  user  and  no  structure  exists 
In  the  ASSM  for  that  element.  An  entry  node  is  created  for  the 
structure  and  displayed  at  the  upper  center  portion  of  the  struc- 
ture display  area.  The  user  may  then  add  to  the  structure  by 
selecting  desired  node  types  via  the  menu. 
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NO  GRAPHICS  DATA  ON  STRUCTURE 


This  message  is  displayed  when  the  structure  for  the  element  name 
supplied  by  the  user  has  no  graphics  coordinate  data  for  Its 
associated  nodes.  The  structure  was  created  and  entered  In  the 
ASSM  via  the  RSL  translator. 

NO  ORDINAL,  ENTER  TRACKBALL  FOR  CONDITIONAL  EXPRESSION 

If  the  user  has  selected  the  display  branch  menu  operation  and 
the  selected  branch  does  not  contain  an  ordinal,  then  the  above 
message  results. 

NO  STRUCTURE  ASSOCIATED  WITH  SELECTED  ELEMENT,  INPUT  REJECTED 

This  message  results  if  an  attempt  Is  made  to  generate  CALCOMP 
output  for  a non-existent  structure.  The  input  request  is  ignored. 

NO  STRUCTURE  AVAILABLE,  SAVE  REJECTED 

This  message  results  when  an  attempt  is  made  to  save  a nonexistent 
structure.  The  request  is  simply  ignored. 

NODE  DEFINITION  IS  INCOMPLETE,  SAVE  REJECTED 

This  message  results  when,  in  an  attempt  to  save  a structure,  an 
AND/OR  node  was  detected  as  having  only  one  Incoming  and  one  out- 
going branch.  The  structure  is  displayed  with  the  node  in  question 
centered  in  the  structure  display  area  surrounded  by  a red,  blue,  end 
whtte  square.  The  structure  remains  In  the  ASSM  In  temporary  status. 

NODE  OVERLAP  IN  STRUCTURE,  REPEAT  SELECTION  SEQUENCE 

This  message  results  when  an  attempt  is  made  to  create/locate  a 
node  which  would  overlap  an  already  existing  node  In  the  structure 
display  area.  The  user  selection  of  the  node  location  Is  ignored; 
however,  the  current  menu  selection  remains  in  force. 

NODE  WILL  NOT  FIT  ON  DRAWING  AREA,  TRY  AGAIN 

This  message  results  when  an  attempt  is  made  to  create/locate  a 
node  either  outside  the  structure  display  area  or  too  near  the 
border  surrounding  the  structure  display  area.  The  user  entry  of 
the  node  location  is  ignored  but  the  current  menu  selection 
remains  in  force. 

NODES  HAVE  BEEN  DISCONNECTED,  CONTINUE 

This  message  is  displayed  upon  completion  of  a disconnect  nodes 
menu  operation.  The  message  informs  the  user  that  the  nodes  were 
successfully  disconnected  In  the  ASSM  and  that  further  processing 
may  now  continue. 

NON-EXISTENT  NODE  SELECTED,  RESTART  SELECTION  SEQUENCE 

T'.is  message  results  when,  in  an  attempt  to  select  a node  in  the 
structure  display  area,  the  screen  position  selected  actually  con- 
tains no  node.  The  position  selection(s)  is  ignored,  however  the 
current  menu  selection  remains  in  force. 
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NOT  EXACTLY  ONE  OTHERWISE  BRANCH  ON  OR  RRANCH,  SAVE  REJECTED 

This  message  results  when,  in  an  attempt  to  save  a structure,  it 
was  determined  that  an  OR  node  (not  a CONSIDER  OR  node)  exists  in 
the  structure  which  does  not  have  one  and  only  one  OTHERWISE 
branch.  The  structure  is  displayed  with  the  OR  node  in  question 
centered  in  the  structure  display  area  surrounded  by  a red,  blue, 
and  white  square.  The  structure  remains  In  the  ASSM  In  temporary  status. 

NOT  EXACTLY  ONE  RETURN  NODE  ON  THIS  SUBNET,  SAVE  REJECTED 

If,  in  the  process  of  attempting  to  save  a SUBNET  structure,  the 
structure  does  not  contain  one  and  only  one  SUBNET  return  node, 
then  the  above  message  results.  The  user  must  correct  the  situa- 
tion before  the  structure  can  be  saved. 

SCROLL  IS  COMPLETE,  CONTINUE 

This  message  is  displayed  upon  completion  of  a SCROLL  net  menu 
operation.  The  message  informs  the  user  that  the  structure  was 
successfully  scrolled  and  that  further  processing  may  now  continue. 

SELECT  FROM  MENU  WITH  TRACKBALL 

This  message  Is  displayed  immediately  upon  entering  the  RNETGEN 
function.  The  only  menu  selection  allowed  at  this  point  is  one  of 
the  following:  one  of  the  structure  types,  color  selection,  or 
the  STOP  command. 

SELECT  NODE  TO  BE  DISCONNECTED 

This  message  is  displayed  after  selecting  the  first  of  the  two 
nodes  to  be  disconnected.  The  user  must  respond  with  a trackball 
selection  of  the  desired  node  to  be  disconnected  from  the  previously 
selected  node. 

SELECT  SUCCESSOR  NODE 

This  message  is  displayed  after  selecting  the  first  (predecessor) 
node  of  the  two  nodes  which  are  to  be  connected.  The  user  must 
respond  with  a trackball  selection  of  the  desired  successor  node. 

SELECTED  NODE  HAS  BEEN  DELETED,  CONTINUE 

This  message  is  displayed  upon  completion  of  a delete  node  menu 
operation.  The  message  informs  the  user  that  the  node  was  suc- 
cessfully deleted  from  the  ASSM,  and  that  further  processing  may 
now  continue. 

SELECTED  NODE  HAS  NO  ASSOCIATED  ELEMENT,  CONTINUE 

This  message  results  when  in  the  display  node  menu  operation  and 
the  selected  node  has  no  element  associated  with  It  in  the  ASSM. 

The  selection  is  ignored  and  the  current  menu  selection  remains 
in  force. 
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SELECT  NODES  HAVE  BEEN  CONNECTED,  CONTINUE 

This  message  is  displayed  upon  completion  of  a connect  nodes  menu 
operation.  The  message  informs  the  user  that  the  nodes  were 
successfully  connected,  and  that  further  processing  may  now 
continue. 


SELECT  - ENTITY_CLASS,  ENTITYJYPE  - ENTER  VIA  TRACKBALL 

When  positioning  a SELECT  node  on  the  screen,  the  above  message  Is 
displayed.  The  user  must  respond  with  a trackball  selection  of  one 
of  the  two  entries  in  the  message. 

SELECT  - PROMPTER  OR  AUTOPLOT  - VIA  TRACKBALL 

This  message  is  displayed  when  the  structure  selected  by  the  user 
has  no  graphics  coordinate  data  for  its  associated  nodes.  The 
structure  was  created  and  entered  in  the  ASSM  via  the  RSL  trans- 
lator function.  The  user  responds  by  selecting  either  the  word 
PROMPTER  or  the  word  AUTOPLOT  in  the  displayed  message  using  the 
trackball.  If  the  PROMPTER  selection  Is  made,  the  user  will  be 
requested  to  develop  the  structure  graphics  using  the  successor 
node  menu  operation.  If  AUTOPLOT  is  chosen,  the  graphics  coordi- 
nate data  are  generated  by  REVS. 


SELECT  - TO  POSITION  - VIA  TRACKBALL 


This  message  results  when  attempting  to  move  a node  or 
the  entire  structure.  The  user  responds  by  selecting, 
trackball,  a position  on  the  screen  to  which  he  wishes 
selected  node  to  be  moved  or,  In  the  case  of  a scroll, 
wishes  a previously  selected  point  on  the  structure  to 
(SCROLLED). 


to  scroll 
via  the 
a previously 
to  which  he 
be  moved 


STRUCTURE  DOES  NOT  HAVE  AN  ENTRY  NODE,  SAVE  REJECTED 

This  message  results  when,  in  an  attempt  to  save  a structure, 
it  has  been  determined  that  no  entry  node  exists  for  trie  structure. 
The  structure  remains  in  the  ASSM  in  temporary  status. 


STRUCTURE  ALREADY  HAS  AN  ENTRY  NODE,  SELECTION  REJECTED 

This  message  results  if  an  attempt  is  made  to  enter  more  than  one 
entry  node  for  a structure.  The  input  is  ignored;  however,  the 
menu  selection  remains  in  force. 


STRUCTURE  HAS  BEEN  SAVED,  CONTINUE 

This  message  Is  displayed  upon  completion  of  a save  net  menu 
operation.  The  message  is  intended  to  inform  the  user  that  the 
structure  was  successfully  entered  in  the  ASSM  in  a permanent 
status,  and  that  further  processing  may  now  continue. 
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STRUCTURE  NEEDS  ADDITIONAL  GRAPHICS  DATA,  SAVE  REJECTED 

This  message  results  when,  in  an  attempt  to  save  a structure,  at 
least  one  node  was  detected  to  have  no  graphics  coordinate  data. 

The  structure  is  displayed  with  the  predecessor  to  the  node  in 
question  centered  in  the  structure  display  area  surrounded  by  a 
red,  blue,  and  white  square.  The  structure  remains  In  the  ASSM 
In  temporary  status. 

SUCCESSOR  NODE  HAS  BEEN  DISPLAYED,  CONTINUE 

This  message  is  displayed  upon  completion  of  a successor  node  menu 
operation.  The  message  is  intended  to  inform  the  user  that  the 
successor  node  operation  was  successful,  and  that  further  process- 
ing may  now  continue. 

SYNTAX  ERROR  WAS  DETECTED  IN  EXPRESSION,  INPUT  REJECTED 

This  message  results  from  a syntax  error  in  a conditional  expres- 
sion on  an  OR/FOR  branch.  The  line  containing  the  error  is  dis- 
played and  the  character  in  error  is  displayed  in  red.  The  desired 
branch  connection  and  associated  conditional  expression  is  rejected. 
The  user  must  re-indicate  nodes  to  be  connected  and  subsequently 
re-input  the  conditional  expression  correctly. 

THERE  ARE  NO  MORE  SUCCESSOR  NODES  ON  SELECTED  NODE,  CONTINUE 

This  message  appears  in  the  successor  node  menu  operation  when 
the  selected  node  has  no  other  successor  nodes  without  graphics 
coordinate  data.  The  node  selection  is  ignored;  however,  the 
current  menu  selection  remains  in  force. 

UNDEFINED  ELEMENTJYPE  FOR  THIS  STRUCTURE,  INPUT  REJECTED 

This  message  results  when  the  structure  type  selected  by  the  user 
has  no  corresponding  element  type  defined  in  the  ASSM.  For 
instance,  if  a subnet  structure  was  selected  from  the  menu  and 
no  element  type  SUBNET  exist*  in  the  ASSM,  then  the  above  message 
is  displayed  and  the  request  is  ignored. 

WARNING  ...  PREVIOUS  STRUCTURE  WAS  NOT  SAVED,  RE-SELECT  MENU 

This  message  results  from  an  attempt  to  begin/select  another  struc- 
ture or  to  stop  (exit  RNETGEN)  prior  to  saving  the  currently  dis- 
played structure.  At  this  point  the  user  may  select  any  appropriate 
menu  operation  including  the  save  net  operation. 

ZOOM-IN  IS  COMPLETE,  CONTINUE 

This  message  is  displayed  upon  completion  of  a ZOOM-IN  on  net  menu 
operation.  The  message  is  intended  to  inform  the  user  that  the 
ZOOM-IN  operation  was  successful,  and  that  further  processing  may 
now  continue. 
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ZOOM-OUT  IS  COMPLETE,  CONTINUE 

This  message  is  displayed  upon  completion  of  a ZOOM-OUT  on  net  menu 
operation.  The  message  informs  the  user  that  the  ZOOM-OUT  operation 
was  successful  and  that  further  processing  may  now  continue. 

ZOOM-OUT  OR  ZOOM-IN  ON  STRUCTURE,  SELECT  VIA  TRACKBALL 

This  message  is  displayed  in  order  to  provide  the  user  with  the 
option  of  displaying  the  selected  structure  In  either  Its  zoomed- 
out  or  its  zoomed-in  form.  The  user  responds  with  an  appropriate 
trackball  selection. 


table  also  includes  the  number  of  the  section  In  this  document  which 
describes  the  corresponding  syntax. 

Figure  F-l  shows  the  syntax  in  diagrammatic  form. 


p 


Table  F.l  RADX  RCL  Index  (Continued) 


.append  definition*: :• 


(ALL  r 

APPEND  (ANY  > 

(element-type-namej.| 


<append  item*::* 

- attribute-name  | relation-name  [relation-optional-word] 

| REFERS  [relation-optional -word]  | REFERRED  [relation-optional -word] 
| ALL  | NONE  | STRUCTURE  | ATTRIBUTE  | RELATION  | RELATIONSHIP 
I PRIMARY  I COMPLEMENTARY 


.list  set*::* 


{punch}  <set  1d>  [<hierarchY  option*]. 


<hierarchy  list  option*: := 


positive  connector*  {hi|rARCHy}^  h1erarch>r-name[<posi  11  ve  connector* 


RADX  RCL  SYNTAX 


| j< append  1tem>|  . 


SECTION 

NUMBER 


MAP 

GROUP 

SEQUENCE 


<1 i st  RSL*::* 

{punch ^ RSL  ^<RSl-  iten>l* 

<RSL  Item*::* 

element-type-name  [SUMMARY] 

| ELEMENTJYPE  | RELATIONSHIP 

| relation-name  | attribute-name  | ALL 
| RELATION  | ATTRIBUTE  | SUMMARY 

<1 ist  permission*: := 

IpunCH)  EMISSION  GIVEN  control -permission-name. 

<plot  size*:  :* 

WIDTH  [=]  number  | HEIGHT  [*]  number 


.analyze  set*::*  ( BETA 

ANALYZE  [DATAJLOW]  <set  id*  USING  (GAMMA 

L I TMD1  T I 


append  definition 


Syntax  Diagrams 


definition 


RADX  RCL  Syntax  Diagrams  (Continued) 


hlerirchy  deMnftlon 


Diagrams  (Continued) 


positive  connector 


Figure  F-l  RADX  RCL  Syntax  Diagrams 


F .2  RADX  DIAGNOSTIC  MESSAGES 

A summary  of  the  error  messages  that  can  be  issued  by  the  RADX  function 
is  listed  below.  All  error  messages  have  the  following  standard  format: 

* ERROR  XXXX  description. 

The  XXXX  is  a unique  four  digit  number  that  appears  with  the  description 
of  each  of  the  following  messages. 

0060  ILLEGAL  KEYWORD  WAS  SPECIFIED. 

0061  BAD  ANALYZE  COMMAND. 

0090  SET  TO  BE  LISTED  DOES  NOT  EXIST. 

0091  BAD  LIST  SET  COMMAND. 

0092  NOT  OPTION  CANNOT  BE  APPLIED  TO  LIST  BY  HIERARCHY. 

0093  INCOMPLETE  LIST  SET  BY  HIERARCHY  COMMAND. 

1 

0094  REFERENCE  TO  UNDEFINED  HIERARCHY. 

0095  BAD  LIST  RSL  SELECTION. 

/ 

0096  INCORRECT  LIST  PERMISSION  COMMAND. 

0100  SET  NAME  CANNOT  APPEAR  IN  THE  ASSM. 

0101  SET  NAME  MUST  BE  ALPHANUMERIC  BEGINNING  WITH  ALPHA. 

0102  SET  NAME  MUST  NOT  BE  AN  RCL  RESERVED  WORD. 

0120  REFERENCE  TO  UNDEFINED  SET  IN  SET  DEFINITION  STATEMENT. 

0180  INCOMPLETE  SET  QUALIFICATION  COMMAND. 

0181  NOT  OPTION  ILLEGAL  WHEN  QUALIFYING  BY  HIERARCHY. 

0182  REFERENCE  TO  UNDEFINED  HIERARCHY. 

0183  BAD  QUALIFY  SET  COMMAND. 

0184  REFERENCE  TO  UNDEFINED  OBJECT  SET  IN  SET  QUALIFICATION. 

0210  REFERENCE  TO  UNDEFINED  SET. 

0240  INCOMPLETE  APPEND  STATEMENT.  - _ 


A 


0241  REFERENCE  TO  UNDEFINED  RSL  ELEMENT  TYPE. 

0242  ILLEGAL  SELECTION  IN  APPEND  STATEMENT. 

0280  SYMBOL  STRING  IS  TOO  LONG. 

0281  CHARACTER  STRING  IS  TOO  LONG 

0320  INPUT  LINE  BUFFER  OVERFLOW  (STATEMENT  IS  TOO  LONG). 

1080  AND-NODE  USED  TO  SPLIT  AND  JOIN,  OR  NEITHER. 

Can  only  be  caused  by  system  error. 

1120  OR-NODE  USED  TO  SPLIT  AND  JOIN,  OR  NEITHER. 

Can  only  be  caused  by  system  error. 

1200  AND-NODE  USED  TO  SPLIT  AND  JOIN,  OR  NEITHER. 

Can  only  be  caused  by  system  error. 

1240  NO  SUCCESSOR  ON  SPLIT  OR-NODE. 

Can  only  be  caused  by  system  error. 

1241  OR-NODE  USED  BOTH  AS  SPLIT  AND  JOIN,  OR  NEITHER. 

Can  only  be  caused  by  system  error. 

1520  RADX  ABORT  FROM  QQERRPRC. 

Message  issued  when  RADX  has  to  abort  because  of  system  error. 

1540  OUT  OF  SET  STORAGE  SPACE. 

The  user  has  exceeded  the  number  of  sets  that  can  be  defined 
in  a single  activation  of  RADX. 

1660  OUT  OF  GLOBAL  WORKING 'SET  SPACE. 

Can  only  be  caused  by  RADX  software  error. 

1790  ASSM  DATA  BASE  ERROR  DETECTED. 

Indicates  that  RADX  is  unable  to  retrieve  information  from  the 
ASSM. 

1800  ATTRIBUTE  VALUE  IS  ILL-FORMED. 

1801  ATTRIBUTE  RELATIONAL  OPERATOR  IS  ILLEGAL  FOR  ATTRIBUTE  VALUE. 

1802  ATTRIBUTE  VALUE  EXPECTED. 

1804  ATTRIBUTE  VALUE  SPECIFIED  IS  ILLEGAL. 
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1820  PRIMARY  RELATION  NAME  STRING  IS  NOT  IN  THE  ASSM. 

Can  only  be  caused  by  system  error. 

1821  PRIMARY  RELATION  OPTIONAL  WORD  STRING  IS  NOT  IN  THE  ASSM. 

Can  only  be  caused  by  system  error. 

1825  PRIMARY  RELATION  INSTANCE  IS  NOT  IN  THE  ASSM. 

Can  only  be  caused  by  system  error. 

1840  COMPLEMENTARY  RELATION  NAME  STRING  IS  NOT  IN  THE  ASSM. 

Can  only  be  caused  by  system  error. 

1841  COMPLEMENTARY  RELATION  OPTIONAL  WORD  STRING  IS  NOT  IN  ASSM. 

Can  only  be  caused  by  system  error. 

1842  PRIMARY  RELATION  FOR  COMPLEMENTARY  RELATION  IS  NOT  IN  ASSM. 

Can  occur  because  of  an  incomplete  RSL  definition. 

1846  PRIMARY  RELATION  INSTANCE  IS  NOT  IN  THE  ASSM. 

Can  only  be  caused  by  system  error. 

1880  COMPLEMENTARY  RELATION  FOR  PRIMARY  RELATION  IS  NOT  IN  ASSM. 
Can  occur  due  to  an  incomplete  definition  of  RSL. 

1920  NO  ELEMENTJYPES  ARE  DEFINED. 

1960  NO  ATTRIBUTES  ARE  DEFINED. 

1961  NO  APPLICABLE  ELEMENTJYPES  ARE  DEFINED. 

1962  NO  ATTRIBUTE  LEGAL  VALUES  ARE  DEFINED. 

1980  NO  RELATIONSHIPS  ARE  DEFINED. 

1981  NO  COMPLEMENTARY  RELATIONSHIP  IS  DEFINED. 

2000  NO  LEGAL  SUBJECTS  ARE  DEFINED. 

2001  NO  LEGAL  OBJECTS  ARE  DEFINED. 

2060  INCOMPLETE  DEFINE  HIERARCHY  STATEMENT. 

2061  DEFINE  HIERARCHY  STATEMENT  TOO  LARGE. 

2062  REFERENCE  TO  UNDEFINED  SET  IN  HIERARCHY  DEFINITION. 

2063  REFERENCE  TO  UNDEFINED  RELATION  IN  DEFINE  HIERARCHY. 


J 
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OUT  OF  DEFINE  HIERARCHY  SPACE. 

Too  many  hierarchies  have  attempted  to  be  defined  during  a 
single  activation  of  RADX. 

TOO  MANY  START  ENTRIES  IN  HIERARCHY. 

Too  many  sets  in  the  hierarchy  definition  have  the  same  name 
as  the  top-of-the-hierarchy. 

HIERARCHY  TOO  COMPLEX. 

There  are  too  many  connections  between  the  entries  in  the 
hierarchy. 

NO  MORE  PROCESSING  ON  CURRENT  PATH  OF  HIERARCHY. 

Indicates  that  an  error  was  detected  while  traversing  a hierarchy 
and  that  the  processing  of  the  hierarchy  is  incomplete. 

TOO  MANY  LEVELS  IN  HIERARCHY. 

The  length  of  a hierarchy  trace  causes  RADX  storage  of  a path  in 
the  hierarchy  to  be  exceeded. 

LOOP  IN  HIERARCHY. 

Indicates  that  a direct  or  indirect  loop  has  been  found  in  a 
requirements  hierarchy. 

LOOP  IN  INFORMATION  NET. 

Indicates  that  a loop  was  detected  in  a requirements  hierarchy 
while  constructing  the  analysis  information  net. 

PATH  IN  INFORMATION  NET  TOO  LONG. 

Indicates  that  a path  in  the  analysis  information  net  Is  too 
long  to  be  stored  in  an  internal  RADX  table. 

REPETITIVE  DATA  SETS  (RDS)  CONTAIN  COMMON  MEMBERS. 

DATA  WITH  USE=BETA  INCLUDED  IN  OTHER  DATA  WITH  USE=BETA. 

DATA  WITH  USE=GAMMA  INCLUDES  OTHER  DATA. 

NO  USE  ATTRIBUTE. 

DATA  SHOULD  HAVE  USE=BETA . VALUE  ASSUMED. 

DATA  SHOULD  HAVE  USE=GAMMA.  VALUE  ASSUMED. 

REFERENCE  TO  UNDEFINED  SET  IN  PLOT  COMMAND. 

PLOT  DIMENSION  TOO  SMALL. 

PLOT  DIMENSION  TOO  LARGE  — REPLACED  BY  MAXIMUM. 


[• 


2563  REAL  NUMBER  ILLEGALLY  SPECIFIED. 

2564  ILLEGAL  SYMBOL  SPECIFIED  IN  PLOT  COMMAND. 

2580  ILLEGAL  PERMISSION  SPECIFIED. 

2600  LOCALITY  OF  REPETITIVE  DATA  SET  AND  MEMBERS  NOT  THE  SAME. 

2620  MESSAGE  CONTENTS  PASSING  OUTPUTJNTERFACE  NEVER  ASSIGNED. 

2621  MESSAGE  CONTENTS  OF  OUTPUTJNTERFACE  POSSIBLY  NOT  ASSIGNED. 

2640  ELEMENT  ON  CONSIDER  OR  IS  NOT  OF  TYPE  DATA  OR  ENTITY_CLASS. 

2641  ELEMENT  ON  CONSIDER  OR  DOES  NOT  HAVE  TYPE  ATTRIBUTE. 

2642  ELEMENT  ON  CONSIDER  OR  HAS  ILLEGAL  VALUE  FOR  TYPE  ATTRIBUTE. 

2643  ELEMENT  ON  CONSIDER  OR  DOES  NOT  HAVE  RANGE  ATTRIBUTE. 

2644  ILLEGAL  NAME  IN  CONDITIONAL  BRANCH  OR  IN  RANGE  ATTRIBUTE. 

2645  ITEM  IN  RANGE  ATTRIBUTE  EXISTS  IN  ASSM. 

2646  ITEM  IN  CONDITIONAL  BRANCH  EXISTS  IN  ASSM. 

2647  DUPLICATE  NAME  ENCOUNTERED  ON  CONSIDER  OR  NODE  BRANCH. 

2648  BRANCH  ITEM  NOT  CONTAINED  IN  RANGE  LIST  ON  CONSIDER  OR. 

2649  ALL  ITEMS  IN  RANGE  LIST  NOT  ENCOUNTERED  ON  BRANCHES. 

2650  ENTITY JYPE  ON  BRANCH  DOES  NOT  EXIST  IN  ASSM. 

2651  DUPLICATE  ITEM  IN  RANGE  LIST. 

2652  ENTITY_CLASS  IS  NOT  COMPOSED  OF  BRANCH  ENTITY  JYPE. 

2653  ALL  ITEMS  IN  COMPOSE  LIST  NOT  ENCOUNTERED  ON  BRANCHES. 

2661  INFORMATION  ALWAYS  REASSIGNED  BEFORE  USED. 

2662  INFORMATION  SOMETIMES  REASSIGNED  BEFORE  USED. 

2663  INFORMATION  SOMETIMES  USED  BEFORE  ASSIGNED. 

2664  INFORMATION  ALWAYS  USED  BEFORE  ASSIGNED. 

2665  POSSIBLE  USE  AND  ASSIGNMENT  FROM  DIFFERENT  PARALLEL  PATHS. 

2666  POSSIBLE  ASSIGNMENT  FROM  MORE  THAN  ONE  PARALLEL  PATH. 

2667  USE  AND  ASSIGNMENT  FROM  DIFFERENT  PARALLEL  PATHS. 
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2668  ASSIGNMENT  FROM  MORE  THAN  ONE  PARALLEL  PATH. 

2669  INFORMATION  ASSIGNED  BUT  NOT  USED. 

2670  INFORMATION  SOMETIMES  ASSIGNED  BUT  NOT  USED. 

2671  SET  ENTITYJYPE  WITHOUT  SELECTED/CREATED  ENTITY_CLASS. 

2672  POSSIBLE  SET  ENTITYJYPE  WITHOUT  SELECTED/CREATED  CLASS. 

2673  DESTROY  ENTITY_CLASS  THAT  IS  NOT  SELECTED. 

2674  POSSIBLE  DESTROY  ENTITY_CLASS  THAT  IS  NOT  SELECTED. 

2675  DISJOINT  INPUT  MESSAGES  REQUIRED  AT  THE  SAME  TIME. 

2676  DISJOINT  INPUT  MESSAGES  POSSIBLY  REQUIRED  AT  THE  SAME  TIME. 

2700  ENTITYJYPE  NOT  SET  FOR  ENTITY_CLASS  BEING  UPDATED. 

2720  MESSAGE  NEVER  FORMED  WHEN  OUTPUTJNTERFACE  TRAVERSED. 

2721  MESSAGE  POSSIBLY  NOT  FORMED  WHEN  OUTPUT  INTERFACE  TRAVERSED. 

2740  ALPHA  FORMS  MORE  THAN  ONE  MESSAGE  THAT  PASSES  SAME  INTERFACE. 

2760  PARTIALLY  REJOINING  AND -CONSTRUCT. 

2780  PARTIALLY  REJOINING  OR-CONSTRUCT. 

2800  REFERENCED  SUBNET  DOES  NOT  HAVE  A STRUCTURE. 

2801  TOO  MANY  NESTED  SUBNET  REFERENCES. 

The  number  of  SUBNET  references  Is  larger  than  that  which  can 
be  processed  by  RADX. 

2820  INFORMATION  PASSING  INPUT  INTERFACE  NOT  USED. 
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APPENDIX  G 
SIMGEN  SUMMARY 

G.l  SIMGEN  RCL  SYNTAX 

Table  G.l  contains  a description  of  the  syntax  of  SIMGEN  RCL  In  the 
BNF  notation  described  in  Appendix  A.  For  each  syntax  production  or  set 
of  productions  for  the  SIMGEN  RCL  commands,  this  table  also  identifies  the 
number  of  the  section  in  this  document  where  the  command  is  described. 


Figure  G-l  shows  the  syntax  of  SIMGEN  RCL  in  diagrammatic  form. 


-r  ^ ~ 


Table  G.l  SIMGEN  RCL  Index 
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G .2  BETA/GAMMA  FILE  ACCESS  SYNTAX 

Table  G.2  contains  a description  of  the  syntax  of  the  REVS  statements 
used  to  perform  file  operations  in  BETA  and  GAMMA  executable  descriptions. 
The  syntax  is  presented  in  the  BNF  described  in  Appendix  A.  As  noted  In  the 
table,  these  statements  are  explained  in  Section  7.1.1. 

Figure  G-2  presents  the  syntax  of  the  file  access  statements  in 
diagrammatic  form. 


> 


Table  G.2  BETA/GAMMA  FILE  Access  Index 


FILE  ACCESS  SYNTAX 


SECTION 

NUMBER 


<f11e  access  statement*:  : = 
<create  statement 
| <destroy  statement* 

| <select  statement* 

| <for  each  statement* 

< create  statement*: := 

CREATE  file-name  RECORD 

<destroy  statement* ::= 

DESTROY  file-name  RECORD 

<select  statement*: := 


SELECT  |nEXTT}^  REC0RD  FR0M  f11e'name 
[SUCH  THAT  (<Boolean  expression*)] 


<for  each  statement*: := 

FOR  EACH  file-name  RECORD  [SUCH  THAT  (<Boolean  expression*)]  DO 
< PASCAL  statement*  ENDFOREACH 


NOTE:  <Boolean  expression*  Is  defined  In  the  RSL  syntax  presented  in  Appendix  D. 
<PASCAL  statement*  Is  defined  to  Include  <file  access  statement*  as  a 
legal  form. 


Syntax  Diagrams  for  BETA/GAMMA  FILE  Access 


G.3  TEST  RECORDING  ACCESS  SYNTAX 


Table  G.3  contains  a description  of  the  syntax  of  the  REVS  statements 
used  to  access  RECORDINGS  in  PERFORMANCE_REQUIREMENT  TESTs.  The  descrip- 
tions are  in  the  BNF  described  in  Appendix  A.  As  noted  in  the  table,  these 
statements  are  explained  in  Section  7.1.2. 

Figure  G-3  presents  the  syntax  of  these  statements  in  dlagranmatic 

form. 


TABLE  6.3  TEST  Recording  Access  Index 


RECORDING  ACCESS  SYNTAX 

SECTION 

NUMBER 

<recordtng  access  statement*  ::  = 

<retr1eve  recording  statement* 

| <for  each  recording  statement* 

| <select  recorded  file  statement* 

| <for  each  recorded  file  statement* 

7.1.2 

<retr1eve  recording  statement* 

RETRIEVE  {next1}}  recording  for  val Idatlon-polnt-name 

[SUCH  THAT  (<Boolean  expression*)] 

<for  each  recording  statement*: : = 

FOR  EACH  val Idatlon-polnt-name  RECORDING 
[SUCH  THAT  (<Boolean  expression*)] 

DO  < PASCAL  statement*  ENDFOREACH 

<select  recorded  file  statement*: : = 

SELECT  |nextT|]  record  from  valldatlon-polnt-name.flle-name 

[SUCH  THAT  (<Boolean  expression*)] 

<for  each  recorded  file  statement*: :■ 

FOR  EACH  val Idatlon-polnt-name. file-name  RECORD 
[SUCH  THAT  (<Boolean  expression*)] 

DO  < PASCAL  statement*  ENDFOREACH 

NOT:  <Boolean  expression  Is  defined  In  the  RSI  syntax  presented  in  Appendix  D. 
< PASCAL  statement  is  defined  to  include  recording  access  statement*  as 
a legal  form. 
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retrieve  recording  statement 


gure  G-3  Syntax  Diagrams  for  Recording  Access 


e G-3  Syntax  Diagrams  for  Recording  Access  (Continued) 


G.4  SIMGEN  DIAGNOSTIC  MESSAGES 
SIMGEN  RCL  Diagnostics 

The  following  errors  are  detected  by  SIMGEN  in  response  to  the  user 
input  RCL  commands.  Each  of  these  error  messages  will  be  preceded  by 
♦ERROR*  and  followed  on  the  next  line  by  a diagnostic  message  of  the  form: 

SYMBOL:  last-symbol -scanned; 

giving  the  last  symbol  scanned  In  the  RCL  command  before  detection  of  the 
error . 

CONFLICT  IN  LIST  TYPES 

INCLUDE  and  EXCLUDE  lists  cannot  both  be  used  In  a single 
generation. 

ERROR  IN  INITIALIZATION 

SIMGEN  could  not  obtain  a pointer  to  element  type  R_NET. 

INPUT  EMPTY 

No  commands  have  been  given  to  enable  generation  of  a simulation. 
PERIOD  MISSING 

The  last  input  statement  did  not  contain  a period  terminator 
(non-fatal ) . 

UNRECOGNIZABLE  STATEMENT 
UNRECOGNIZABLE  SYMBOL 

After  completion  of  SIMGEN  parsing,  the  following  diagnostic  messages 
may  occur. 

SIMULATION  SCOPE  (PARTIAL  OR  ENTIRE)  NOT  DEFINED. 

SIMULATION  GENERATION  CANNOT  BE  PERFORMED. 

SIMGEN  did  not  receive  an  RCL  input  specifying  which  R_NETs  were  to 
be  Included  in  the  simulation. 

SIMULATION  TYPE  (BETA  OR  GAMMA)  NOT  SPECIFIED. 

SIMULATION  GENERATION  CANNOT  BE  PERFORMED. 

SIMGEN  did  not  receive  an  RCL  input  specifying  whether  the  simulation 
should  be  a beta  type  or  a gamma  type. 

Data  Base  Analysis  Diagnostics 

Prior  to  translating  the  contents  of  the  ASSM  into  executable  simula- 
tion code  SIMGEN  executes  the  ANALYZE  capability  of  RADX  (see  Section  6.3). 
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Diagnostics  output  by  RADX  In  support  of  SIM6EN  are  documented  In  Appendix 
F,  Section  2. 

SIMGEN  Translation  Diagnostics 


/ 


The  following  errors  are  detected  by  the  SIMGEN  function  while  construct- 
ing an  executable  simulation  from  the  contents  of  the  ASSM. 

A F0R_EACH  WITHIN  A PR  TEST  HAS  NO  MATCHING  ENDFOREACH 

This  message  will  be  accompanied  by  the  name  of  the  PERFORMANCE 
REQUIREMENT. 


ALPHA  alpha-name  HAS  NO 


(BETA  V 
)GAMMA(.| 


The  BETA  or  GAMMA  attribute  for  the  named  ALPHA  cannot  be  found 
in  the  ASSM.  SIMGEN  has  represented  this  ALPHA  with  a dummy 
procedure  In  the  simulator  program. 


ASSM  ERROR  DETECTED  AT  CHECK  POINT  number. 

SIMGEN  encountered  an  error  In  accessing  the  ASSM.  The  number 
indicates  the  point  in  the  process  at  which  the  error  occurred. 
Report  the  error  to  the  REVS  maintenance  group. 

ENDFOREACH  DOES  NOT  HAVE  A MATCHING  F0R_EACH 

This  message  will  be  accompanied  by  the  name  of  the  PERFORMANCE 
REQUIREMENT. 

EVENT  NAME  NOT  FOUND  FOR  R NET  R-Net-name. 

~ 

There  Is  no  enabling  event  for  the  R NET. 

PERFORMANCE_REQU IREMENT  COULD  NOT  BE  ACCESSED  IN  ASSM 

This  message  will  appear  when,  through  some  Internal  system 
error,  the  PERFORMANCE  REQUIREMENT  could  not  be  accessed  in  the 
ASSM. 


PERFORMANCE_REQU IREMENT  TEST  COULD  NOT  BE  ACCESSED  IN  ASSM 

This  message  will  appear  If  there  Is  no  TEST  or  If,  through  some 
Internal  system  error,  the  TEST  could  not  be  accessed  in  the  ASSM. 
The  message  will  be  accompanied  by  the  name  of  the  PERFORMANCE 
REQUIREMENT. 

SIMGEN  ASSM  ERROR  PRINT  DISABLED. 

The  printing  of  ASSM  access  errors  has  been  disabled  after  the 
detection  of  twenty-five  errors. 
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SYNTAX  ERROR  IN  PERFORMANCE  REQUIREMENT  TEST 

This  message  will  be  accompanied  by  the  name  of  the  PERFORMANCE_ 
REQUIREMENT  and  the  name  of  the  function  being  translated.  In 
addition  the  name  of  the  VALIDATION  POINT,  the  name  of  the  VALI- 
DATI0N_P0INT  FILE,  and  the  number  of  the  word  in  error  will  appear 
if  known  and  applicable. 
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TEST  IS  NOT  IN  THE  ASSM  OR  IS  NOT  AN  ATTRIBUTE 

This  message  will  appear  when  the  attribute  TEST  has  been  deleted 
from  the  language  or  when  TEST  is  no  longer  an  attribute. 

{CREATE  ^ 

FOR1 EACH l * STATEMENT  IN  *al pha-name*  CONTAINS  AN  ERROR:  OPERAND 
SELECT 

♦identifier*  NOT  FOUND  IN  DATA  BASE. 

A statement  in  the  BETA/GAMMA  text  of  the  indicated  ALPHA  has 
an  operand  that  is  not  in  the  ASSM.  The  statement  is  treated 
as  PASCAL. 


CREATE  V 

"*  STATEMENT  IN  *alpha-name*  CONTAINS  SYNTAX  ERROR. 

[select  \ 

A statement  in  the  BETA/GAMMA  text  of  the  indicated  ALPHA  is  not 
consistent  with  the  syntax  defined  in  Section  7.1.1. 


{CREATE 

forTeach( 

SELECT 


* STATEMENT  IN  *al pha-name*. 


A statement  in  the  BETA/GAMMA  text  of  the  indicated  ALPHA  has  an 
operand  that  is  not  of  type  FILE.  The  statement  is  treated  as 
PASCAL . 


r 


♦identifier*  IS  ^oujpuj^by}  *a^Pha-name** 
NOT  CONSISTENT  WITH  SPECIFIED  REQUIREMENTS. 


SIMGEN  has  detected  the  indicated  relationship  in  the  BETA/GAMMA 
text  of  the  named  ALPHA.  The  relationship  is  not  included  in  the 
requirements  that  have  been  specified  for  this  ALPHA. 


♦identifier*  WAS  NOT 


(USED  IN  \] 
{OUTPUT  BY 


*al pha-name*. 


For  the  indicated  ALPHA,  there  is  an  INPUTS  or  OUTPUTS  relation- 
ship, with  the  identifier  as  the  object,  that  is  not  implemented 
in  the  BETA/GAMMA  text. 
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OPERAND  OF  * 

•/CREATE  l1* 
(DESTROY^ 


DESTROY  ||  * N0T  F0UND  IN  *a^ pha-name*. 
DELETED  FROM  ALPHA  TEXT. 


There  is  a syntax  error  in  a CREATE  or  DESTROY  statement  in  the 
BETA/GAMMA  text  of  tne  indicated  ALPHA.  SIM6EN  was  unable  to 
find  the  operand  of  the  statement,  and  the  operator  (e.g., 
CREATE)  wa's  not  translated. 


0342  DATA- ITEM  ENUMERATED  TYPE  HAS  NO  ATTRIBUTE  OF  RANGE 

A data  element  has  the  attribute  TYPE  with  a value  of  ENUMERATION 
but  the  data  element  does  not  have  the  attribute  RANGE. 


0343  DATA -ITEM  HAS  ENUMERATED  TYPE  BUT  NO  RANGE  ATTRIBUTE  AADBPTR 

A data  element  has  the  attribute  TYPE  with  a value  of  ENUMERATION 
but  the  definition  of  the  attribute  RANGE  cannot  be  located  in  the 
ASSM.  Either  it  has  been  deleted  from  the  language,  RANGE  is 
defined  in  the  ASSM  but  not  as  an  attribute,  or  there  has  been  a 
system/hardware  error. 

0344  DATA-ITEM  HAS  AN  UNKNOWN  TYPE  ATTRIBUTE  STRING 

A data  element  has  the  attribute  TYPE  but  the  value  is  not  REAL, 
INTEGER,  BOOLEAN,  or  ENUMERATION. 

0345  DATA-ITEM  TYPE  ATTRIBUTE  HAS  A BAD  STRING  SEGMENT 

A data  element  has  the  attribute  TYPE  but  the  value  could  not  be 
accessed  from  the  ASSM  due  to  a system/hardware  error. 

0346  DATA-ITEM  HAS  NO  ATTRIBUTE  OF  TYPE 

A data  element  does  not  have  the  attribute  TYPE. 

0347  NO  TYPE  ATTRIBUTE  AADBPTR 

The  definition  of  the  attribute  TYrE  could  not  be  located  in  the 
ASSM.  Either  it  has  been  deleted  from  the  language,  TYPE  is 
defined  in  the  ASSM  but  not  as  an  attribute,  or  there  has  been 
a system/ hardware  error. 

0521  DATA-ITEM  INITIAL  VALUE  HAS  A BAD  STRING  SEGMENT 

The  value  of  the  attribute  INITIAL  VALUE  for  a data  element 
could  not  be  accessed  due  to  a faulty  ASSM. 

0523  NO  INITIAL  VALUE  ATTRIBUTE  AADBPTR 

The  definition  of  the  attribute  INITIAL  VALUE  could  not  be  located 
in  the  ASSM.  Either  it  has  been  deleted"  from  the  language, 
INITIAL_VALUE  is  defined  in  the  ASSM  but  not  as  an  attribute,  or 
there  has  been  a system/hardware  error. 
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0681  LOCALITY  IS  NOT  AN  ATTRIBUTE 


7 


l 

A L 


LOCALITY  is  defined  in  the  ASSM  but  not  as  an  attribute. 

0682  LOCALITY  IS  NOT  IN  THE  ASSM 

The  definition  of  LOCALITY  has  been  deleted  from  the  language. 

0683  TYPE  IS  NOT  AN  ATTRIBUTE 

TYPE  is  defined  in  the  ASSM  but  not  as  an  attribute. 

0684  TYPE  IS  NOT  IN  THE  ASSM 

The  definition  of  TYPE  has  been  deletH  from  the  language. 

0685  RANGE  IS  NOT  AN  ATTRIBUTE 

RANGE  is  defined  in  the  ASSM  but  not  as  an  attribute. 

0686  RANGE  IS  NOT  IN  THE  ASSM 

The  definition  of  RANGE  has  been  deleted  from  the  language. 

0687  INITIALJ/ALUE  IS  NOT  AN  ATTRIBUTE 

INITIALJ/ALUE  is  defined  in  the  ASSM  but  not  as  an  attribute, 

0688  INITIALJ/ALUE  IS  NOT  IN  THE  ASSM 

The  definition  has  been  deleted  from  the  language. 

0701  FILE  NAME  STRING  IS  BAD 

The  name  of  a FILE  element  could  not  be  accessed  due  to  a system/ 
hardware  error. 

0741  MESSAGE  NAME  STRING  IS  BAD 

The  name  of  a MESSAGE  element  could  not  be  accessed  due  to  a 
system/hardware  error. 

0742  INTERFACE  NAME  STRING  IS  BAD 

The  name  of  an  INTERFACE  element  could  not  be  accessed  due  to  a 
system/ hard ware  error. 

0801  FILE  LOCALITY  ATTRIBUTE  STRING  IS  BAD 

The  value  of  the  attribute  LOCALITY  of  a FILE  element  could  not 
be  accessed  due  to  a system/hardware  error. 

0802  ATTRIBUTE  LOCALITY  IS  ABSENT 

The  definition  of  the  attribute  LOCALITY  could  not  be  located  in 
the  ASSM.  Either  it  has  been  deleted  from  the  language,  LOCALITY 
is  defined  in  the  ASSM  but  not  as  an  attribute,  or  there  has  been 
a system/hardware  error. 

0821  ENUMERATED  TYPE  VALUE  STRING  HAS  MORE  THAN  AASTRLEN  CHARCTRS 

The  length  (in  characters)  of  an  enumeration  value  name  is  more 
than  60  characters.  (See  the  definition  of  the  attribute  RANGE.) 
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0824 


0825 


0841 


0842 


0843 


0844 


0861 


0881 


0941 


0942 


ENUMERATED  TYPE  RANGE  SEGMENT  IS  BAD 

The  value  of  the  attribute  RANGE  could  not  be  accessed  due  to  a 
system/hardware  error. 

ENUMERATED  TYPE  ENDED  UNEXPECTEDLY  (NO  DOUBLE  QUOTE) 

The  syntax  specifying  the  value  of  the  attribute  RANGE  Is 
incorrect  indicating  a system/hardware  error. 

ENUMERATED  TYPE  DOES  NOT  BEGIN  WITH  DOUBLE  QUOTE 

The  syntax  specifying  the  value  of  the  attribute  RANGE  is 
incorrect  indicating  a system/hardware  error. 

ENUMERATED  TYPE  HAS  AN  EMPTY  (ZERO-LENGTH)  VALUE 

The  syntax  specifying  the  value  of  the  attribute  RANGE  is 
Incorrect  indicating  a system/hardware  error. 

CLASS  DATA  ITEM  NAME  STRING  IS  BAD 

The  name  of  a DATA  element  could  not  be  accessed  due  to  a system/ 
hardware  error. 

ENTITY_TYPE  NAME  STRING  IS  BAD 

The  name  of  an  ENTITY_TYPE  element  could  not  be  accessed  due  to 
a system/hardware  error. 

ENTITY_CLASS  NAME  STRING  IS  BAD 

The  name  of  an  ENTITY_CLASS  element  could  not  be  accessed  due  to 
system/hardware  error. 

CLASS  FILE  NAME  STRING  IS  BAD 

The  name  of  a FILE  element  could  not  be  accessed  due  to  a system/ 
hardware  error. 

INSTANCE  FILE  NAME  STRING  IS  BAD 

The  name  of  a FILE  element  could  not  be  accessed  due  to  a system/ 
hardware  error. 

INSTANCE  DATA-ITEM  NAME  STRING  IS  BAD 

The  name  of  a DATA  element  could  not  be  accessed  due  to  a system/ 
hardware  error. 

SIMPLE  DATA  LOCALITY  STRING  IS  BAD 

The  value  of  the  attribute  LOCALITY  could  not  be  accessed  due  to 
a system /hard ware  error. 

ATTRIBUTE  LOCALITY  IS  ABSENT 

The  definition  of  the  attribute  LOCALITY  could  not  be  located  In 
the  ASSM.  Either  it  has  been  deleted  from  the  language,  LOCALITY 
is  defined  In  the  ASSM  but  not  as  an  attribute,  or  there  has  been 
a system/hardware  error. 
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0343  SIMPLE  DATA  NAME  STRING  IS  BAD 

The  name  of  a data  element  could  not  be  accessed  due  to  a system/ 
hardware  error. 

5000  VALIDATION  POINT  NAME  STRING  CANNOT  BE  ACCESSED  IN  ASSM 

The  name  of  a VALIDATION_POINT  could  not  be  accessed  due  to  a 
system/h«s.rdware  error. 


APPENDIX  H 


SIMXQT  SUMMARY 


SIMXQT  RCL  SYNTAX 


Table  H.l  contains  a description  of  the  syntax  of  SIMXQT  RCL  in  the 
BNF  notation  described  in  Appendix  A.  For  each  syntax  production  or  set 
of  productions  for  the  SIMXQT  RCL  commands,  this  table  also  Identifies  the 
number  of  the  section  in  this  document  where  the  command  is  described. 


Figure  H-l  shows  the  syntax  of  SIMXQT  RCL  in  diagranmatic  form. 


Table  H.l  SIMXQT  RCL  Index 


SIMXQT  RCL  SYNTAX 

<SIMXQT  comnand>::= 

<start  time  declarat1on> 

<end  time  declaration> 

| <simulation  run  ident1ficat1on> 

7.4 

< start  time  declarations : = 

[SIMULATOR1]  START  [TIME]  = real -number. 

7.4.1 

<end  time  declaration>: := 

[siMLAToT]  end  ■ real-number. 

7.4.1 

<simulation  run  identification>: := 

RUN  INDENT  > [IS]  identification-name. 

[51MULATUK  J (IDENTIFICATION  ) ] 

H 

H-2 


Figure  H-l  SIMXQT  RCL  Syntax  Diagram 


H.2  SIMXQT  DIAGNOSTIC  MESSAGES 

The  following  errors  are  detected  by  SIMXQT  in  response  to  the  user 
Input  RCL  commands.  Each  of  these  error  messages  will  be  preceded  by 
♦ERROR*  and  followed  on  the  next  line  by  a diagnostic  message  of  the  form: 

SYMBOL:  last-symbol -scanned; 

giving  the  last  symbol  scanned  in  the  RCL  command  before  detection  of  the 
error . 

ERROR  IN  REAL  NUMBER 
INPUT  EMPTY 
PERIOD  MISSING 

TIME  MUST  BE  LARGER  THAN  -1 .0E4 
UNRECOGNIZABLE  STATEMENT 
UNRECOGNIZABLE  SYMBOL 

The  execution  of  the  simulation  requires  the  input  of  both  a start 
and  end  time,  with  the  end  time  greater  than  the  start  time.  If  these 
inputs  have  not  been  correctly  provided,  the  following  diagnostics  will  be 
produced: 


END  TIME  NOT  SPECIFIED 
START  TIME  NOT  SPECIFIED 
START  TIME  >=  END  TIME 


***** 


QUl ED 


H.3  SIMULATOR  PROGRAM  DIAGNOSTIC  MESSAGES 


Initialization  Diagnostics 

During  the  Initialization  phase  of  a simulator  program  execution,  the 
user  supplied  start  and  end  times  are  read  Into  the  simulator  program  from 
a file  (the  EESUIF)  constructed  by  the  SIMXQT  function.  The  following 
diagnostics  may  occur: 

START  TIME  NOT  INPUT 

No  start  time  was  found  on  the  EESUIF. 

END  TIME  NOT  INPUT 

No  end  time  found  on  the  EESUIF. 

The  simulator  program  initialization  also  reads  another  file,  the  EEDF,  con- 
structed by  SIMGEN.  In  reading  this  file,  simulator  Initialization  will 
verify  that  it  is  the  correct  file.  The  following  diagnostics  may  occur: 

NO  EEDF  FILE  PROVIDED 

No  EEDF  file  is  available. 

EEDF  FILE  DOES  NOT  MATCH  THE  SIMULATION  PROGRAM  TEXT 

The  EEDF  file  read  in  was  not  created  by  the  same  SIMGEN  execu- 
tion as  was  the  simulator  program. 

If  any  of  the  above  errors  was  detected  during  initialization,  the 
following  diagnostic  will  be  output  and  the  simulator  program  will  not  be 
executed. 

SIMULATION  PROGRAM  CANNOT  BE  EXECUTED 
Execution  Diagnostics 

ATTEMPTED  BACKUP  IN  TIME,  EVENT  IGNORED,  TIME  = simulation-time 
ATTEMPTED  CAUSE  OF  AN  UNKNOWN  EVENT,  EVENT  IGNORED,  TIME  = simulation-time 
EVENT  NAME  IS  event-name 

An  attempt  has  been  made  to  cause  an  event  which  is  not  known  to 
the  simulator  event  manager.  The  event  will  be  ignored. 

EVENT  NAME  IS  event-name  EVENT  TIME  * desired-event-time 

An  attempt  has  been  made  to  cause  an  event  to  occur  at  an  earlier 
time  than  current  simulation  time.  The  event  is  ignored. 
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VALIDATION  POINT  = xxxx  } 

NO  OWNER  SELECTED  FOR  • 

A VAL IDAT ION_PO INT  attempted  to  RECORD  DATA  which  Is  either 
• CONTAINED  In  a FILE  or  ASSOCIATED  with  an  ENTITY  TYPE  or  ENTITY_ 
CLASS  and  the  recording  was  attempted  without  a TILE  record  or 
entity  having  been  previously  selected;  or  the  VALIDATION_POINT 
attempted  to  RECORD  a FILE  ASSOCIATED  with  an  ENTITY_TYPE  or 
ENTITY_CLASS  without  an  entity  having  been  selected.  This  message 
will  be  preceded  by  a message  Identifying  the  name  of  the 
VALIDATION  POINT.  (Note  that  xxxx  Is  the  ordinal  of  the  VALIDATION 
POINT  at  wHich  recording  was  attempted.) 

4001  NO  SET  TYPE  FOR  A NEW  ENTITY_CLASS  INSTANCE 

An  instance  of  an  entity-class  was  created  and  is  now  being  de- 
selected but  a SET  operation  has  not  been  done  to  establish  the 
type. 

4021  DATA-SET  INSTANCE  STATUS  IS  OLD  BUT  NO  INSTANCE  PRESENT 

A system  Internal  error  occurring  when  an  entity  or  FILE  record 
to  be  de-selected  Is  marked  as  existing  but  the  pointer  to  It  Is 
NIL. 

4061  SELECT  NEXT  WITH  NO  SELECT  FIRST  OR  WITH  NO  FOUND  CHECK 

A SELECT  with  a NEXT  option  has  encountered  a "no  current  instance" 
condition.  This  may  occur  If  a SELECT  with  a FIRST  option  has  not 
preceded  It  or  if  the  global  data  element  REC0RD_F0UND  has  not  been 
monitored  properly  to  determine  that  no  instance  is  selected. 

4201  DATA-SET  HEADER  BEING  LOADED  INTO  FROM  INSTANCE  IS  NOT  EMPTY 

An  error  detected  on  the  selection  of  an  entity  which  ASSOCIATES 
a FILE;  there  Is  already  a FILE  In  existence  which  Is  not 
attached  to  an  entity.  This  can  occur  by  creating  a FILE  without 
having  previously  selected  or  created  the  entity  and  then  per- 
forming a SELECT  or  FOR  EACH  on  the  ENTITY_CLASS  or  ENTITYJYPE. 

4241  DATA-SET  BEING  COPIED  INTO  IS  NOT  EMPTY 

A system  Internal  error  occurring  on  the  establishment  of  a 
MESSAGE. 

4281  INSTANCE  TO  BE  DESTROYED  IS  LOCKED  BY  A FOR-EACH 

A DESTROYS  ENTITY  CLASS  has  been  encountered  Inside  of  a FOR  EACH 
operation  on  a FlCE  ASSOCIATED  with  the  currently  selected  entity 
of  the  ENTITY  CLASS. 
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4301  DATA-SET  HEADER  TO  BE  DESTROYED  IS  NOT  EMPTY 

A system  internal  error  occurring  on  the  destruction  of  a MESSAGE 
or  ENTITY  TYPE  (or  class)  which  MAKE  a FILE  or  ASSOCIATES  a FILE, 
respectively.  The  condition  is  abnormal  because  the  FILE  should 
have  been  destroyed  earlier. 

4341  ATTEMPT  TO  SAVE  ENTITY_CLASS  WITH  NO  ENTITYJYPE  SELECTED 

A system  Internal  error  occurring  on  the  save  portion  of  a FOR 
EACH  operation. 

4342  ATTEMPT  TO  SAVE  ENTITY_TYPE  WHICH  IS  NOT  SELECTED 

A system  Internal  error  occurring  on  the  save  portion  of  a FOR 
EACH  operation. 

4343  ATTEMPT  TO  SAVE  DATA-SET  WHICH  HAS  NO  VALID  INSTANCE  SELECTED 

A system  Internal  error  occurring  on  the  save  portion  of  a FOR 
EACH  operation. 

4361  ATTEMPT  TO  RESTORE  ENTITYJYPE  WHICH  IS  NOT  IN  ENTITY_CLASS 

A system  Internal  error  occurring  on  the  restore  portion  of  a FOR 
EACH  operation. 

4362  ATTEMPT  TO  RESTORE  DATA-SET  WHICH  WAS  NOT  SAVED 

A system  internal  error  occurring  on  the  restore  portion  of  a FOR 
EACH  operation. 

4363  ATTEMPT  TO  RESTORE  A NON-EXISTENT  INSTANCE 

A system  internal  error  occurring  on  the  restore  portion  of  a FOR 
EACH  operation. 

4401  DESTROY  ENTITY_CLASS  WITH  NO  ENTITY  SELECTED 

An  error  occurring  on  the  destruction  of  an  instance  of  an  entity- 
class  when  no  instance  is  selected. 

4402  DESTROY  DATA-SET  WITH  NO  INSTANCE  SELECTED 

A DESTROY  operation  on  a FILE  has  been  encountered  when  no  record 
is  selected  in  the  FILE. 

4441  SET  TYPE  ON  ENTITY_CLASS 

A system  internal  error  - SETS  has  been  attempted  on  an  ENTITY_ 
CLASS. 

j 

4442  SET  TYPE  ON  FILE  OR  INTERFACE 

A system  internal  error  - SETS  has  been  attempted  on  a FILE  or 
interface. 


H-9 


i 


4443  SET  TYPE  WITH  NO  NEW  OR  SELECTED  ENTITY 


An  error  occurring  when  a SETS  ENTITY_TYPE  operation  Is  done 
without  an  entity  being  selected. 

4444  SET  TYPE  WITH  AN  INVALID  INSTANCE  SELECTED 

An  error  occurring  when  a SETS  ENTITY_TYPE  operation  Is  done 
without  an  entity  being  selected. 

4501  ATTEMPT  TO  TERMINATE  A NON-OUTPUT-INTERFACE 

A system  Internal  error  occurring  when  a data-set  which  Is  not 
an  Interface  Is  terminated. 

4502  A MESSAGE  WAS  NOT  FORMED  ON  AN  OUTPUTJNTERFACE 

An  error  occurring  when  an  OUTPUT  INTERFACE  Is  encountered 
without  a MESSAGE  having  been  FORffed  for  the  interface. 

4541  DATA-SET  TYPE  INCONSISTENT  WITH  CURRENT  INSTANCE  POINTER 

A system  Internal  error  occurring  on  the  restore  portion  of  a 
VALIDATION_POINT  execution.  The  data-set  (or  specifically  - file) 
name  saved  during  the  save  portion  of  the  VALIDATION_POINT  execu- 
tion does  not  agree  with  the  data-set  name  passed  to  the  restore 
function.  This  Is  the  first  of  two  different  cross  checks  to 
guarantee  restoration  of  the  same  data-set  as  that  saved. 

4542  CURRENT  STATIC  DATA  POINTER  IS  NIL 

A system  Internal  error  occurring  on  the  restore  portion  of  a 
VALIDATION_POINT  execution.  The  pointer  to  a dynamically  allo- 
cated record  of  the  file's  original  environment  Is  NIL.  This 
condition  Is  abnormal  because  the  record  Is  allocated  and  the 
pointer  set  during  the  save  portion  of  a VALIDATION_POINT  execu- 
tion (which  precedes  the  restore). 

4543  DATAJSET  TYPE  INCONSISTENT  WITH  STATIC  DATA  POINTER 

A system  Internal  error  occurring  on  the  restore  portion  of  a 
VALIDATION_POINT  execution.  The  data-set  (or  specifically  - file) 
name  saved  during  the  save  portion  of  the  VALIDATION_POINT  execu- 
tion does  not  agree  with  the  data-set  name  passed  to  the  restore 
function.  This  Is  the  second  of  two  different  cross  checks  to 
guarantee  restoration  of  the  same  data-set  as  that  saved. 
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APPENDIX  I 
SIMDA  SUMMARY 


1.1  SIMDA  RCL  SYNTAX 


Table  1.1  contains  a description  of  the  syntax  of  the  SIMDA  RCL  com- 
mand in  the  BNF  notation  described  in  Appendix  A.  The  section  number 
appearing  in  the  table  identifies  the  section  of  this  document  where  the 
command  is  described. 

Figure  1-1  shows  the  SIMDA  RCL  syntax  in  diagrammatic  form. 


SIMDA  RCL  SYNTAX 

SSJH 

<SIMDA  comma nd>: := 

tpct  an  TpERFORMANCE  REQUIREMENT  ~) 
itii  all  [jERFORMANCE^EQUIREMENTSj  * 

1 TFCT  ai  i fypfpt  fPERF0RMANCE  REQUIREMENT  1 

1 .til  all  tALtr  [j>ERF0RMANCE_REQUIREMENTS_J 

| performance-requirement-name 

. TrcT  f PERFORMANCE  REQUIREMENT  l/n^fnwianro  Mnil^omont  namo^ 

1 TEST  (j5ERF0RMANCE_REQUIREMENTSj  (performance"re^uiremen^"name^.j  • 
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Figure  1-1  SIMDA  RCL  Syntax  Diagram 


1.2  SIMDA  DIAGNOSTIC  MESSAGES 


The  Simulation  Data  Analysis  Function  (SIMDA)  must  read  in  a file, 
the  EEDF,  created  by  SIMGEN  to  obtain  the  names  of  PERFORMANCE_REQUIREMENTs 
included  In  the  simulation.  If  the  EEDF  file  is  missing  or  contains  no 
PERFORMANCE_REQUIREMENT  names,  then  SIMDA  will  output  the  following  diag- 
nostic and  will  terminate. 

NO  PERFORMANCE_REQUIREMENTS  AVAILABLE  FOR  TESTING 

The  following  errors  are  detected  by  SIMDA  in  response  to  the  user 
input  RCL  commands.  Each  of  these  error  messages  will  be  preceded  by 
*ERR0R*  and  followed  on  the  next  line  by  a diagnostic  message  of  the  form: 

SYMBOL:  last-symbol -scanned . 

giving  the  last  symbol  scanned  before  detection  of  the  error. 

CONFLICT  IN  LIST  TYPES  I 

Only  one  form  of  the  TEST  list  may  be  given.  If  ALL  or  ALL  EXCEPT 
was  used,  no  other  list  may  be  specified. 

INPUT  EMPTY 

i 

PERIOD  MISSING 

The  last  input  statement  did  not  contain  a terminating  period. 

This  error  does  not  affect  the  processing  of  that  statement. 

UNRECOGNIZABLE  STATEMENT 

UNRECOGNIZABLE  SYMBOL 


i 


1.3  SIMULATION  POST  PROCESSOR  DIAGNOSTIC  MESSAGES 


Initialization  Diagnostics 

During  the  initialization  phase  of  a simulation  post  processor  execu- 
tion, the  recording  data  base  and  the  validation  Information  file  are 
correlated  with  the  simulator  post  processor  program  to  guarantee  compati- 
bility. If  some  irregularity  is  discovered  during  this  check,  one  of  the 
following  messages  will  be  issued. 


VP  RECORDING  DATABASE  COULD  NOT  BE  OPENED 

This  message  will  appear  when  through  some  Internal  system  or 
user  error  the  recording  data  base  could  not  be  opened. 


VP  RECORDING  DATABASE  HEADER  IS  ABSENT 

This  message  will  appear  when  through  some  internal  system  or  user 
error  the  recording  data  base  identification  data  Is  missing. 

RECORDING  DOES  NOT  MATCH  TEST 

This  message  will  appear  when  the  recording  data  base  input  to 
the  simulation  post  processor  program  was  not  generated  by  the 
simulator  which  matches  the  simulation  post  processor  program 
(i.e.,  both  were  created  by  Simulation  Generation  at  the  same 
time).  This  message  will  be  accompanied  by  the  time,  date,  and 
ID  of  creation  for  both  the  recording  data  base  and  the  simula- 
tion post  processor  program. 


VALIDATION  INFORMATION  FILE  (VVIF)  IS  EMPTY 

This  message  will  appear  when  no  validation  information  file  has 
been  supplied. 


VA L IDAT 1 0N_I NFORMAT 1 0N_F  I L E HEADER  DOES  NOT  AGREE  WITH  TEST 

This  message  will  appear  when  the  validation  information  file 
input  to  the  simulation  post  processor  program  was  not  generated 
from  the  simulator  which  matches  the  simulation  post  processor 
program . 

NO  VALIDATION  POINT  INSTANCES  RECORDED  IN  DATABASE 

This  message  will  appear  when  no  DATA  was  recorded  at  any  VALIDA- 
TI0N_P0INT  during  the  simulator  execution. 

VAL IDATI0N_P0I NT  xxxx  HAS  NO  RECORDINGS  IN  THE  DATABASE 

This  message  will  appear  when  no  data  was  recorded  at  validation 
point  xxxx  (where  xxxx  Is  the  validation  point  ordinal)  during  the 
simulator  execution.  In  the  post  processor,  there  Is  a retrieval 
procedure  corresponding  to  each  VALIDATION_POINT  In  the  simulator; 
the  name  of  the  procedure  is  VVxxxx  where  xxxx  Is  the  validation 
point  ordinal.  The  RSL  name  of  the  VALIDATION_POINT  appears  In  a 
comment  directly  following  the  retrieval  procedure  heading. 
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Execution  Diagnostics 

PERFORMANCE  REQUIREMENT  performance-requirement-name  NOT  FOUND 

This  message  will  appear  when  the  user  has  requested  execution  of 
a performance  requirement  test  that  could  not  be  found. 


Table  J.l  contains  a description  of  the  syntax  of  RSL  Extension  com- 
mands in  the  BNF  notation  described  in  Appendix  A.  For  each  syntax  produc- 
tion or  set  of  productions  for  the  RSL  Extension  commands,  this  table  also 
Identifies  the  number  of  the  section  in  this  document  where  the  command  is 
described.  Note  that  an  RSL  command  (the  syntax  for  which  Is  summarized  in 
Appendix  D)  Is  a legal  command  to  the  RSL  Extension  (RSLXTND)  function. 

Figure  J.l  shows  the  syntax  of  RSL  Extension  commands  In  diagrammatic 

form. 

J.2  RSLXTND  DIAGNOSTIC  MESSAGES 

The  diagnostic  messages  output  by  the  RSLXTND  function  are  the  same  as 
those  output  by  the  RSL  function  and  are  documented  in  Section  5 of  Appendix  D. 
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Table  0.1  RSL  Extension  Index 


RSI  EXTENSION  SYNTAX 

SECTION 

NUMBER 

<RSL  Extension  command*:  :■ 

<extens<on  control  command* 

| <new  element  type  definition* 

| <e1ement  type  modification* 

| <e1ement  type  deletion* 

| <new  attribute  definition* 

| attribute  modification* 

| <attr1bute  deletion* 

| <new  relation  definition* 

| <re1at1on  modification* 

| relation  deletion* 

1 <RSL  cormand 

8.0 

<extens1on  control  command*: :* 

IDENTIFICATION  name. 

| EXTENSI0N_PERMISSI0N  name. 

| CONTROL_PERMISSION  name. 

RESCIND  PERMISSION  name. 

8.1 

<new  element  type  definition*::* 

[DEFINE]  ELEMENT_TYPE  element-type-name  comment. 

|[ INSERT]  <structure  applicability  declaration*^ 

<structure  applicability  declaration*::* 

STRUCTURE  APPLICABILITY 

8.2.1 

<element  type  modification*::* 

[MODIFY]  ELEMENT_TYPE  element-type-name  [comment]. 

{ [remove]  <structure  applicability  declaration 

8.3.1 

< element  type  deletion* ::■ 

DELETE  ELEMENT_TYPE  element-type-name. 

8.4.1 

< new  attribute  definition* : :■ 

[OEFINE]  ATTRIBUTE  attribute-name  comment. 

^[INSERT]  <attr1bute  definition  sentence*^ 

<attr1bute  definition  sentence*::* 

applicable  type  declaration* 

| < legal  value  declaration* 

applicable  type  declaration* ::■ 

| APPLICABLE  [ELEMENTJYPE]  <element  types*. 

< element  types* ::• 

.all 

| [ALL  EXCEPT]  |element-type-name  | ^ 

«legal  value  declaration* 

1 NUMERIC  \ 1 

VALUE  \ NAMED  ^ [comment]. 

(value-name  ) 1 

8.2.2 
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Table  J.l  RSL  Extension  Index  (Continued) 


RSL  EXTENSION  SYNTAX 


•Attribute  modification* : :• 

[MOO IF Vj  ATTRIBUTE  attribute-name  [coement]. 

( [INSERT]  attribute  definition  sentence*  i" 
\ (applicable  type  declaration  removal*  \ 

( (legal  value  declaration  removal*  I n 


•applicable  type  declaration  removal*::* 

I AIL 

REMOVE  APPLICABLE  [ELEHENT_TYPE]  | {«lement-type-nane|* 


•legal  value  declaration  removal*: :■ 


REMOVE  VALUE 


NUMERIC 

TEXT 

NAMED 

value-name 


•attribute  deletion*: :■ 

DELETE  ATTRIBUTE  attribute-name. 


•new  relation  definition*: :■ 


[DEFINE]  {Relationship } ' r«'«tlon-nai»e  [ (“relation-optional -morO] 

comen  t.  1 

{[INSERT]  •relation  definition  sentence*^ 


•relation  definition  sentence*::* 

•complementary  relation  declaration* 
| (Subject  type  declaration* 

I «object  type  declaration* 


•complementary  relation  declaration*: :• 


COMPLEMENTARY  { R ^ lAT  1 ON  SHIP  1 1 [ ("relation-optional  -monC)]. 


•subject  type  declaration*: :• 

SUBJECT  [EIEMENT_T*PE]  (element  types*. 


•object  type  declaration*: :• 

OBJECT  [ELEMENT  TVPf]  (element  types*. 


•relation  modification*.  ■ 


[MODIFY]  { 


RELATION 

RELATIONSHIP 


relation-name  [( ‘relation-optional -word*)] 


[cement]. 

I [INSERT]  «re!atton  definition  sentence*  i" 
•complementary  relation  declaration  removal*! 
•sjbject  type  declaration  removal*  I 

•object  type  declaration  removal*  ' Q 


•complementary  relation  declaration  removal*: :• 

REMOVE  COMPLEMENTARY  relation-name 

[(*re1at1on-opt1onal-«ord*)] 


•subject  type  declaration  removal »::• 
REMOVE  SUBJECT  [CLEMENT JYPE] 


•relation  deletion*:  :• 


(RELATIONSHIP! 


relation-name  [ ("relation-optional -nord*)]- 
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Figure  J-l  RSL  Extension  Syntax  Diagrams 


Extension  Syntax  Diagrams  (Continued) 
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Extenston  Syntax  Diagrams  (Continued) 
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Figure  J-l  RSL  Extension  Syntax  Diagrams  (Continued) 


rolatlon  modification 


Extension  Syntax  Diagrams  (Continued) 
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